Re: user authentication via TCPSend

This WebDNA talk-list message is from

2005

It keeps the original formatting. numero = 63394
interpreted = N
texte = John,Rats; that's what I was afraid of. The situation is that I've built a membership database (on my server) for my Mac user group, and naturally it gives everyone their own login so they can update their data. Meanwhile, the main website (hosted with a local ISP) has a members area with a single login. Ever since we incorporated the membership database, it's been confusing for people to have the two passwords. So they want the individual passwords to give members access to the main site (which is desirable anyway, to not have a single login). The folks in charge of the main site have minimal experience (only html), so to have them incorporate individual passwords on the main server itself is a pipe dream.I just resolved it by doing a simpler [redirect] with user:pass@. I had to create a special landing page for them with a meta refresh redirecting to their member index page to erase the user:pass from the URL. So all is good so far.Thanks for saving me time by telling me the path I was on was not possible.Terry> John Peacock wrote:> Terry Wilson wrote:>> I have a TCPConnect and TCPSend to log into a site with directory>> protection. But it's not making the authentication 'stick' with the>> browser.>>Yeah, that's not going to work. The issue is that since the browser>itself isn't doing the logging in, the browser is unable to cache the>login information.>>> What I'm trying to do is maintain a user database on my server so we>> can authenticate the users via the database, then pass them onto the>> club's main site at another server.>>I would actually turn your model inside out:>>1) end user attempts to login to main site;>2) main site consults the user database on other server;>3) main site caches the successful login locally and uses that from then>on to authenticate with the browsers' cached authentication.>>Alternatively, just skip the second server entirely and have all>authentication happen on the main site. This entire scheme smells like>premature optimization. It is also pretty daft (IMNSHO) to have a>single login to the main site, since you are unable to know who it was>that was logged in.>>HTH>>John-- Terry Wilson | terry@terryfic.com | http://terryfic.comhttp://WhosComing.com - a simplified, affordable online reservation systemhttp://TightPods.com -- stylish protection for your laptop--------------------------------------------------------------------------Attitude is the only difference between ordeal and adventure.-------------------------------------------------------------This message is sent to you because you are subscribed to the mailing list .To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/ Associated Messages, from the most recent to the oldest:

Re: user authentication via TCPSend ( Terry Wilson 2005)
Re: user authentication via TCPSend ( John Peacock 2005)
user authentication via TCPSend ( Terry Wilson 2005)

John,Rats; that's what I was afraid of. The situation is that I've built a membership database (on my server) for my Mac user group, and naturally it gives everyone their own login so they can update their data. Meanwhile, the main website (hosted with a local ISP) has a members area with a single login. Ever since we incorporated the membership database, it's been confusing for people to have the two passwords. So they want the individual passwords to give members access to the main site (which is desirable anyway, to not have a single login). The folks in charge of the main site have minimal experience (only html), so to have them incorporate individual passwords on the main server itself is a pipe dream.I just resolved it by doing a simpler [redirect] with user:pass@. I had to create a special landing page for them with a meta refresh redirecting to their member index page to erase the user:pass from the URL. So all is good so far.Thanks for saving me time by telling me the path I was on was not possible.Terry> John Peacock wrote:> Terry Wilson wrote:>> I have a TCPConnect and TCPSend to log into a site with directory>> protection. But it's not making the authentication 'stick' with the>> browser.>>Yeah, that's not going to work. The issue is that since the browser>itself isn't doing the logging in, the browser is unable to cache the>login information.>>> What I'm trying to do is maintain a user database on my server so we>> can authenticate the users via the database, then pass them onto the>> club's main site at another server.>>I would actually turn your model inside out:>>1) end user attempts to login to main site;>2) main site consults the user database on other server;>3) main site caches the successful login locally and uses that from then>on to authenticate with the browsers' cached authentication.>>Alternatively, just skip the second server entirely and have all>authentication happen on the main site. This entire scheme smells like>premature optimization. It is also pretty daft (IMNSHO) to have a>single login to the main site, since you are unable to know who it was>that was logged in.>>HTH>>John-- Terry Wilson | terry@terryfic.com | http://terryfic.comhttp://WhosComing.com - a simplified, affordable online reservation systemhttp://TightPods.com -- stylish protection for your laptop--------------------------------------------------------------------------Attitude is the only difference between ordeal and adventure.-------------------------------------------------------------This message is sent to you because you are subscribed to the mailing list .To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/ Terry Wilson

DOWNLOAD WEBDNA NOW!

Re: user authentication via TCPSend

2005

Top Articles:

Related Readings: