Passing homegrown session ID's

Tekime

Hello all, I have a few questions about passing my session ID's around.

Something about PHP's built in session manager rubs me the wrong way, and both as a learning experience and just to see if I can make a system that works better for me, I'm trying to make my own session management class.

I actually ran across an older thread in which mrmufin shared some detailed info on how he manages sessions (thank you mrmufin, I know I didn't even post but your info was really helpful).

My question is regarding passing the sid around. Right now cookies make things really easy, but when it comes to using the GET and POST methods of passing the sid, will it be necessary to manually append the SID to every GET and manually insert a hidden field for every POST?

Will I have to insert a hidden sid field in every form I have, and append the sid to every clickable URL on my site, or is there an easier way?

It's easy for me to use PHP's session handler and pull the sid out of session variables, but it also doesn't feel as secure to me.

I have also thought about using a combination of methods: using PHP sessions but maintaining a session DB to verify and track every session (like check IP, agent, etc. with sid entry).

Thanks for any help, knowledge or ideas in advance!

bbaassiri

im not sure why you wouldn't want to re-use something that has been tested and proven. Why is it that you want to do your own session management?

Tekime

Originally posted by bbaassiri
im not sure why you wouldn't want to re-use something that has been tested and proven. Why is it that you want to do your own session management?

Well, I'll try and explain as best I can, and please contradict me if you think I'm misunderstanding anything regarding PHP's session handling.

a) To better understand sessions in the first place. I am no seasoned coder, and I learn best when I can build something myself and see exactly how it works.

b) More control. Using my basic session class I can set cookie and session timeouts, keep session data in the db and actively control where it goes from there.

c) Security. AFAIK if PHP detects a cookie with an active session ID it will assume it's safe and use that session. I want to verify the session ID along with IP and user agent to prevent any form of hijacking.

Feel free to debunk my understanding of PHP's current implementation of session management. Basically, my goal is to have a high level of control, tracking and security in my session implementation. If that means using PHP's session capabilities alongside my own tracking and authentication functions that's fine, I just want the most secure and forward thinking method for my code.

Thanks for the reply.

Tekime

bump

Anyone got any ideas?

michael

If you're truly concerned about security, set sessions to 15 minutes or whenever the user closes the browser, and use SSL (HttpS).

Sessions are truly secure. They're not meant to be. Add your security measures.

Tekime

Originally posted by michael
If you're truly concerned about security, set sessions to 15 minutes or whenever the user closes the browser, and use SSL (HttpS).

Sessions are truly secure. They're not meant to be. Add your security measures.

I'm assuming you mean aren't truly secure? 🙂 I do understand I can implement other security measures to strengthen PHPs session security as well. I'm not going to use SSL for all my code, and I do have session expirations set to a reasonable expire on my server also.

I take it nobody sees any point in managing your own sessions, but does anyone at least know if I would have to manually pass my session id's around in the case that I did use my own management? Is this the only option? If so I will probably use a combination of PHP sessions and my own db tracking, but I would still like to understand what would be involved in taking over session resposibilities myself.

Thanks again, sorry if this post is unclear I'm half awake... :o 🙂

ednark

you could take pains to append your session id to every url link on your site...

you could use a cookie... assign a cookie that only holds your session id, then when the user returns, have your session handling functino retrieve the data stored by that id...

however... as you have probably noticed, this is what php does for you ... if you use either of these approaches, you should just use the built in php session handling...

im not sure if anyone has thought up a better scheme for passing sessions around that involves just browsers and the http protocol.

i know i haven't. but don't let that stop you from trying to find a better way, don't assume other people are right just because they say so.

maybe your wheel will be rounder than their wheel, there can never be to many wheels out there.

Tekime

Well, thanks for the vote of confidence ednark 🙂

im not sure if anyone has thought up a better scheme for passing sessions around that involves just browsers and the http protocol.

Hehe, I don't think I'm prepared to attempt that; although a little more control in my scripts would be nice.

I think what I will probably end up doing is using a combination of PHP sessions and my own tracking. This way I don't have to worry about appending my own SID's on every URL and in every form.

I have already changed my class around a little to start using PHP session ID's instead of my own. We'll see how things fare...

MrAlaska

PHP $_SESSION bases a lot of its methodology on the old PHP_LIB. You might pick up some interesting ideas picking through that script:
http://homepage.mac.com/ghorwood/php_lib_login/

As far as PHP sessions go, they can be just as secure as building your own by registering environmental variables as $_SESSION variables then validating against those.

Native sessions give you a great deal of funtionality for a couple lines of code, but it is not for free. Done right, you can build a more efficient and scalable solution by tailoring it to your own needs.

For passing the URL, I have a class that checks the cookie variable and builds the URL and form inputs as needed. Some of my code looks surprisingly similar to mrmufin's g I actually now use a session class, so whenever I make a local URL I wrap it in $session->append(link.php) and whenever I make a form I add a line inside it $session->insert_form(). Of course, you could do it with functions just as well and actually more efficiently but I like the OO approach because sessions just seem to fit it so well.

It is a slight bit more work to code, but the code performs exactly how I want it with no surpises, while every once in a while $_SESSIONS will throw a curve at you.

I do NOT think there is any advantage to a hybrid approach. I think it is best to use one or the other. If you use session_start() you are paying for them once already, might as well let them do the work 😃

subscript

Support for JavaScript is just as sketchy as for cookies
but... in case it is of any use to you --
I found this bit of script somewhere and modified it a little for one application;
it auto-appends a sessionid var to every URL link and form action on a page.

=============================

for(i = 0; i < document.links.length; i++)
{
with(document.links)
{
href = addvar(href, 'lid', '0f1bedd5fde279c1eebfb039ec862dda');
}
}
for(i = 0; i < document.forms.length; i++)
{
with(document.forms)
{
action = addvar(action, 'lid', '0f1bedd5fde279c1eebfb039ec862dda');
}
}
</script>

=============================

Another thought --
wondering if you could use something like the Apache mod_rewrite module to automatically append a sessionid to your URLs?
http://httpd.apache.org/docs/mod/mod_rewrite.html

Any other comments or thoughts out there on this topic... ?

Are you still working on this -
what did you end up doing?

I'd be interested in hearing...

Cheers.