tags:

views:

96

answers:

2

My service communicates with a server that manages accounts.

  • Each Account has a cap on the number of operations performed per month.
  • I want to circumvent this cap by creating new accounts that are related via a scheme.

This is how it should work:

  1. User creates an account "denzel" via MyService.
  2. MyService in turn, proxies the account creation to 3rdPartyServer
  3. User "denzel" checks his credit and MyService returns $45 (default cap per user account).
  4. User "denzel" buys additional $45 via MyService. MyService surreptitiously creates (in the background) account A in 3rdPartyServer but manages the relation between "denzel" & "A".
  5. User "denzel" checks his credit and MyService returns $90

A dumbass way to manage the relation is to append a count to the original userid. e.g. "denzel1", "denzel2" etc.. This does not work we don't want to prevent other users from choosing denzel1" or others in the series for that matter.

Has anyone faced this problem and has a solution to share ?

+3  A: 

Use a reference table to manage the mappings between real users and generated users. That way you can check if you have already generated an account with a given name.

geowa4
+2  A: 

Why do the accounts created automatically at 3rdPartyServer need to be based on the original user's login? You might as well randomly generate them and then manage them seamlessly "in house" so that user doesn't even need to know about them. As George said, use a Reference table that allows you to cross reference a user of your system with all of their generated aliases.

ninesided
Good point. I might as well just generate a GUID everytime and use that for the 3rdPartyServer. Bingo!
Jacques René Mesrine
yep, that's the ticket. The tricky bit now is how you make it appear seamless. Especially if it is possible that a user can end up with $1 in each of two accounts and try to perform a $2 action!
ninesided