I am creating a soap service where users will be able to interact with each other. They will have a contact list where people can be added. One of the security measures(others are in place, too) is to have a local ID assigned to a contact.
To make the process clear, imagine the following scenario:
$UserA prompts $UserB to be added to $UserA's contact list. $UserB accepts and $UserA receives a local ID to use as UserID referring to the contact. The database contains a table called USER_MAP(LocalID,UserID).
1) Do you think this is a valid approach when dealing with user ids security? If not, why? 2) If you deem it valid, can you suggest a formula to generate said IDs?
At the moment, the idea for the formula is: ($UserA_ID+$UserB_ID)*($UserA_RegDate+$UserB_RegDate)
Consider RegDates as being in "number of days since the 0 date value".
Each user might have 1..N local ids depending on how many users are willing to add. A local ID is local to the user but global in the user space, i.e. for every interaction between users the same local id is used. To make it clearer: if $UserA requests to see $UserB profile, he will be passing the local user id which will be mapped at the server level to the correct id.
Just to make it clear: future does not mean "in a long time from now, maybe, who knows", rather means : "it is planned, I want to do it, I want to make sure I have my pieces ready and THEN I will do it" :) Thus, it's not a "maybe" rather just a matter of WHEN.
Apparently someone has issues understanding the logic behind the approach of a local id. A couple ideas that can help you understand why it's a good idea(in my opinion):
If your ID is local instead of global, you have only access to your own resources/contacts. Useful for instance to avoid programmatically getting access to a profile you wouldn't be allowed to see. This with third parties may be a problem, especially in case of unfair uses
If your ID is local, you can use it as a shortcut for local data instead of having to go to the original account. The contact list could, for instance, hold some of the original data which isn't going to change.
If you have a local id it's much easier to "cut the wire", because all you have to do is deleting one or two records. Say that a user wants to delete a contact. All I will have to do is to remove at best two records, all the other data stays there untouched and simply filtered out by the queries.
Thank you for your time!