Eric - if you require a unique identifier, it sounds like you've got some
pre-processing capabilities on your side. Enforce one with your clients -
even if you "backend" the username and create a random, locally stored,
username for their domains. The way the system is built, you can have
multiple domain names associated with a username/password/<name> subset so
that you can manage multiple domains simultaneously :)
If you ARE going to "backend" your system (i.e. assume administrative
control for your clients) you must make them aware of this in your
contracts.
For your second question, yes, we do use cookies after initial
authentication to maintain a user session. Cookies expire at the hour, and
30 minutes after the hour, every hour (server side)
Charles Daminato
OpenSRS Product Manager
Tucows Inc. - [EMAIL PROTECTED]
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Erik Aronesty
> Sent: September 4, 2001 5:53 PM
> To: [EMAIL PROTECTED]
> Subject: API questions : unique user ids and cookie passing
>
>
> I have two questions which may be obvious, biut I haven't been
> able to find
> the answers in the docs/reference implementation of the API. If
> anyone has
> the answers to these, it would be appreciated.
>
> 1> Is there a single user ID that you get get from the opensrs API (after
> you log in) that *uniquely* identifies a user?
>
> We need to associate additional features with users (not with
> domain names),
> when they log on to the opensrs system and the
> "domainname/username/password" is not an acceptable key, since the domain
> name gets mapped to a "primary account" internally.
>
> Is there any way to find out what the "primary account" is when a
> reg_user/reg_pass logs in? It looks like the "get_user_info" stuff isn't
> enough.
>
> 2> Also, does anyone know if cookies be passed between servers? To
> distribute load, we need to log in on one system and complete back-end
> processing on another. IE: one server logs in, the other gets passed
> session info, and continues processing. For security reasons we'd rather
> NOT pass the username and password - just the one-time session cookie.
>
> - Erik
>
>
>
>
