Public ID is a combination of client internal id and random id

[michalmarcinkowski]

Is there any reason why public ID is a combination of Client internal id and it's random id? (https://github.com/FriendsOfSymfony/FOSOAuthServerBundle/blob/0c72d8baf707dce59c59a4daa1549c06e510bbed/Model/Client.php#L80)

Is there any advantage of doing this https://github.com/FriendsOfSymfony/FOSOAuthServerBundle/blob/0c72d8baf707dce59c59a4daa1549c06e510bbed/Model/ClientManager.php#L29?

I suppose that public ID shouldn't be combined with internal client id, because it makes it unpredictable and we are not able to create a client with desired public ID.

E.g. I would like to have a sample server client loaded on my application demo and a sample API client demo which will 'know' the client_id, but the application demo server reloads database after constant time interval (purges and loads sample data), so the server client id changes and I my sample API client demo does not work...

I could simply override the client model and the client manager to use directly randomized string instead of it's combination with id, but I was wondering if there is any logical/security argument why is it working that way?

[Spomky]

AFAIK, there is no reason. You are right, this could be considered as a security issue as the internal ID of the entity can be retreived by everybody. These classes should be updated, but it will create a BC break as existing clients will not be found.

To be discussed

[michalmarcinkowski]

@Spomky Thanks for quick reply!

Ok, so I will override this behavior. If you will decide to update it in the core, let me know I can prepare a PR with this change.

[corentin-cres]

Hi, i'm having the exact same issue today. The PR seems to have been merged in Sylius project, but didn't get through the FOSOAuthServerBundle ?

Is there a reason for that ?

[er1z]

Probably due not to make backward-incompatible changes.

[dkarlovi]

It can get merged in master which will be 2.x.