The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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

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.

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.

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 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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.