Just to add to this, you should probably make the cookie a session cookie
and have an identical variable, with an associated expiry time, in a
centralized store that each server can check for each request. If the
session has expired then the server deletes the cookie and the user is
forced to re-authenticate. For each valid request you would also need to
update the expiry time.
I am currently working on something similar to this for a site.
If you give more details of what exactly you would want the technology to
do I can probably bundle it in to a few custom tags.
spike
At 10:23 15/03/2001 Thursday, you wrote:
>Implementing some kind of Microsoft Passport technology on top of Spectra
>would also be kind of cool, and make Spectra the number one choice for
>Intranets. Basically what happends is one server is designated as passport
>control, and this is the server that everybody logs into. When they've
>logged in, passport control records a cookie in the users browser. When I
>try and get into a site I'm not logged into, my browser is redirected to the
>passport control server, which reads my cookie and checks to see if I'm
>allowed into the request site. If I am, the passport control server
>encrypts my details and sends them back to the required application by
>redirecting my browser. Software on the application can read these
>encrypted details and thus log me onto the application. The application
>does not then have access to my password, only the passport server has all
>the details.
>
>The passport server can then use SiteMinders NT domain authentication. The
>main point I'm seeing in this thread is, 'Who much do I trust my
>developers?', and this is where I see code reviews as invaluable.
>
>Anyone interested in working on this technology?
>
>-Maddog
>WildFusion
>
> >> -----Original Message-----
> >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> >> Sent: 15 March 2001 06:00
> >> To: Spectra-Talk
> >> Subject: RE: Automatic Login
> >>
> >>
> >> >I think the scheduled process would be unnecessary. If
> >> you're offloading
> >> >your authentication to NTLM and a user does not exist in
> >> the Spectra db, you
> >> >would simply create an account (or even be really cool and
> >> send them to a
> >> >profile page on their first "hit" where they could
> >> customize some of their
> >> >info)
> >> -- Agreed. The more I think about this way of doing
> >> things, the more it makes sense. I don't see any obvious
> >> security holes... you're not going to be able to access any
> >> .cfm templates unless you first get by the webserver
> >> security, thus your NT username and password must be
> >> entered. Hypothetically I could see a user logging in with
> >> their NT username and password and then somehow modifying
> >> cgi.auto_user when it's sent to the server, thus letting
> >> them access someone elses account if they knew someone
> >> elses username... oohh well.
> >>
> >>
> >> >As far as unscrupulous developers go, there's not much
> >> protection from them
> >> >under any circumstances so no point in complicating things
> >> to avoid things
> >> >that simply can't be avoided.
> >> -- The only way a developer is going to get access to
> >> Jeremy's NT password in the aforementioned example is by
> >> using a password cracking tool on the local machine or a
> >> network sniffer, which hopefully a network admin would notice.
> >>
> >> Aaron
> >>
> >>
> >>
> >>
> >>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/spectra_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
