ASP cookieless login script

[afgmail]

I need to implement a login system without using session (or cookies) using a database as backend.
Can someone recommend an existing script to look at to get ideas?
Thanks in advance.

[bslintx]

store a name and password for each user, when they get to login screen simply have them enter who they are-name and their password and better yet you could use their UNIQUE email address to verify and store that in the database....create a user profile...let them submit the info.....use cdo to email info w/ link back to your site....this way you KNOW for sure if it's a person or a bot because they have to "click" on the link when they receive the email. then when they get to your site put the email in the database along w/the other form info...just a thought..it's late;-)

if on an intranet...use serverVariables("LOGON_USER") and let win authenticate them

good luck

[afrika]

difficult or near impossible task.

Are u trying to reinvent the wheel ?
Afrika

[M. Johansson]

I'm using a cookieless user tracking system for my site. It basically uses a hash of the IP and useragent combined to track the users. It's very clean and doesn't need messy and unsecure session ids in the urls.

[afrika]

I'm using a cookieless user tracking system for my site. It basically uses a hash of the IP and useragent combined to track the users. It's very clean and doesn't need messy and unsecure session ids in the urls.

what if the user is using a proxy ?

[M. Johansson]

what if the user is using a proxy ?

That is only and issue if the proxy is constantly rotating it's IP. If it does, well, the user better have cookies on.

[afrika]

Originally Posted by M.Joansson
That is only and issue if the proxy is constantly rotating it's IP. If it does, well, the user better have cookies on.

I personally dont think its an efficient way.

One of our branch offices uses a small VSAT solution, and our provider puts them on a shared proxy server, which when picked up with request.servervariables("remote_addr") it picks the same IP for all browsers.

In this case your login session would be flawed with your employed approach.

I think its neater and better to use either sessions or cookies.

Afrika

[gRoberts]

I have created a way that works without having to use the browser for anything apart from the user entering and leaving.

Basically I use ini files to control my web site, from page titles, login's etc. When the user log's in, it will write their details to the ini file. Each time they visit a page, it will use datadiff to check the time the user it active, if the user is unactive for an amount of time the it removes their details from the ini file and they have to log in again.

Which means, no sessions, no cookies, nothing, and when the user leaves, their user details are removed from the ini file until next time.

Gav

[afrika]

Guess u have reinvented the wheel
:-)

[gRoberts]

at present It's nothing really to shout about, but using an ini file as a database could be my next step, encrypt everything, which I would suppose would stop people from having to pay more for SQL databases or access db integration to their hosts.

Just use a standard script.

But heh, it will happen one day. ( blue moon )

Gav

[afrika]

#10
gRoberts
SitePoint Zealot



Join Date: Oct 2004
Location: gateshead
Posts: 125
at present It's nothing really to shout about, but using an ini file as a database could be my next step, encrypt everything, which I would suppose would stop people from having to pay more for SQL databases or access db integration to their hosts.

Just use a standard script.

But heh, it will happen one day. ( blue moon )

Gav

You might be the next albert einstien,....

... then again you might not be :-)
:-0

[bslintx]

i personnaly like not having to use cookies(100%) of the population vs...90+ percent....yeah +-5 margin but that could literally equal thousands not having capabilities...btw reeinventing the wheel is sometimes a GOOD thing...it's thinking outside the box and this is how technology progresses instead of relying on "that's just the way it is" thinking...good job gav

[afgmail]

Thanks everyone for your input, interesting approaches to the same issue.
gRoberts, can you share the code?

[M. Johansson]

I personally dont think its an efficient way.

One of our branch offices uses a small VSAT solution, and our provider puts them on a shared proxy server, which when picked up with request.servervariables("remote_addr") it picks the same IP for all browsers.

I realize there are instances where shared IPs are used, which is why I have added the useragent string into the tracking. This is of course still flawed, because the users may have the same useragent strings as well, but I know no other distinct information that can be aquired from the client.

I think its neater and better to use either sessions or cookies.

I fully agree. My site uses cookies extensively. The IP/useragent identification is only a fallback if the browser disallows session cookies (which is very uncommon). Also, there is no such thing as "session tracking". Sessions is not a technology per se, and uses either cookies or session IDs in the url to track a user. The last solution is in my opinion highly undesirable from a security, SEO and usability standpoint, which is why I do not use them.

[M. Johansson]

I have created a way that works without having to use the browser for anything apart from the user entering and leaving.

Basically I use ini files to control my web site, from page titles, login's etc. When the user log's in, it will write their details to the ini file. Each time they visit a page, it will use datadiff to check the time the user it active, if the user is unactive for an amount of time the it removes their details from the ini file and they have to log in again.

Yes, but how do you technically track the user? Session IDs in urls?

[afrika]

Originally posted by M.Johansson
I fully agree.

I realize there are instances where shared IPs are used, which is why I have added the useragent string into the tracking. This is of course still flawed, because the users may have the same useragent strings as well, but I know no other distinct information that can be aquired from the client.

Go with the flow...

.... else fight the flow

Afrika

[afgmail]

Google found this: http://www.pgilchrist.ca/.

[otweb]

Probably not the best way in terms of performance, but couldn't you simply save the user's login & pass in hidden form fields after the login form. Then compare it to the db at the top of every page you wish to secure.

Maybe I'm missing something here.

[M. Johansson]

Probably not the best way in terms of performance, but couldn't you simply save the user's login & pass in hidden form fields after the login form. Then compare it to the db at the top of every page you wish to secure.

Maybe I'm missing something here.

That works if every request is a POST, which works, but breaks the back button and opening of new windows.

[afgmail]

Hello Mattias,
I have the following example: example.
In this example I am using hidden fields to transfer auth credentials from one page to the other, and back works...I am using POST to navigate from main to prot01, prot02 and 03...
I know the username and password can be seen on the code, but this is only an example, I will encrypt the userID somehow.

[M. Johansson]

Pretty sweet! Still breaks GET functionality, though, and requires quite much fiddling to implement compared to my solution. With mine, I always have access to the userid in the same way (regardless of whether the use makes use of cookies or not) and I don't need to mess with the user interface at all - no session id's in urls or hidden form fields.

[jpomranky]

This is good stuff!

[gRoberts]

well at present the only thing stopping my coding from working is the amount of coding it could take, well to create a database, if I were to use a standard sql/access database, then my login would work regardless of the users browser, system settings etc, infact the only thing it does it write information to an ini file, which is encrypted.

I'll work on an easy to view code, as I found the ini read and write scripts online, its just using them in the write way that gets the results.

Watch this space.

Gav