Member Pages .... Re: [thesite] user selecteble stylesheets..

[Mark Nickel]

"Warden, Matt" wrote:

> i was assuming it would be an encrypted version of userid... in your doc
> you talk about not needing to query the database and just running off the
> cookie. well, freddy, we need the userid in the cookie then  =)

Yup, I can see that now IF you couldn't/didn't want to query the USERS table based on
the text contained within the user_name cookie.  From a Database H4x0r perspective, of
course querying by the user_id will be more efficient than by the text name...

Ideally I'd like to see the ueue_id be used in the USERS table *as* the user_id.
However, this might not be possible in the current w.e.o. architecture...  I believe
that it is possible, but is yet to be determined in the conversion phase... :)


> >So when I'm redirected back to w.e.o. ColdFusion sets session variables are set by
> >querying the User table using my user_name cookie.
>
> So... we need synched member tables again, eh?

Maybe...  I mean that the ColdFusion code on the w.e.o site, is setting session
variables based on querying the USERS table using the user_id or user_name contained in
the cookies.  There will be values that are stored in USERS table that are not needed in
the UEUE tables.

The UEUE table will be something like this:
user_id
user_name
user_first_name
user_last_name
user_email
user_password

Maybe there would be user_priv field too.  I don't want to start putting role-based
information into ueue.evolt.org unless we want more stuff centralized...  That just
keeps upping the antie towards a XML-RPC/synchronization solutoin.

If we need to pass more fields from ueue.evolt.org then they'll be passed in the
cookies...

Of course they'll all be signed/MD5'ed with the secret_ueue_key.. :)

Granted there is a limit to the amount of data we want to be passing in the cookies.
However, the other way involves putting in XML-RPC/SOAP/"web services" that the
ColdFusion code running on w.e.o can make calls to the ueue.evolt.org web services to
dynamically look up the data that's not stored in the cookies...  This is an
infrastructure that will take a while because it's not a simple client-server database
query.  One has to assume that the subsites are on completely different networks from
ueue.evolt.org.  Hence the perceived "value" of Sun ONE/J2EE and .Net... ahem.. :)

You've already discussed such a synchronization scheme...  Joshua has also outlined
details using XML cruft.

Updating information on ueue.evolt.org
---------------------------------------
We are working on a method for subsite *.evolt.org and ueue.evolt.org to know when UEUE
information is getting updated or subsite user information is needing to be updated...
We are going to try and model this in our prototype....
With clever redirection URLs I believe this will be totally transparent to the user.

Always gotta have ACDF .. Add, Change, Delete Functionality.  :)


> ... then why not userid rather than username?
>
> >Ok, in reality this probably should be USERID instead of user_name (which would be
> >the WHO field??), but in this example, mnickelhome, should be stored in the USERS
> >table.
>
> i really should read the entire email before replying...

:)

we can use that then...  I believe during the conversion to UEUE, the ueue_id will *be*
the user_id in the existing USERS table... Just a hunch.. :)

whew!  this thread/UEUE subject may be even longer than the power cubes!! :)  :)
Also,  Please feel free to slap me with a trout if I get out of line!  :)  I have thick,
flame retardent skin!  :)

Mark


--
"Caution: Cape does not enable user to fly."

-Batman costume warning label