<!-- m --><a class="postlink" href="http://www.whiteazn.com/satworld/admin/">http://www.whiteazn.com/satworld/admin/</a><!-- m -->
i did some php code that creates SESSION variables for some member only pages .....
if you go to the login page (and youve never been there before), and looking at the source code, it has this:
<input type="hidden" name="PHPSESSID" value="7abdbb135665f030a9ae786672cb4cbb" />
it seems to just throw that in there on its own (as i obviously didnt put that into the code)
then a couple times, even though i have not been able to reproduce it since, it changes my links from:
a href=http://www.htmlforums.com/archive/index.php/main.php
to:
a href=http://www.htmlforums.com/archive/index.php/main.php?PHPSESSID=7abdbb135665f030a9ae786672cb4cbb
what causes this? anything i need to worry about?
thanksI'm not too used to php, but I don't think you should worry about it. Maybe there's more than one request from different computers so there's more than one session open and it's labelling them to keep them seperate, but don't take my word for it.yeah, PHPSESSID is a variable used to store session specific variables, so when you pass data on that's session specific it's stored in here. So don't worry about it, it's just helpin you out
even though, its not there now that im looking at it and got my member pages up and working?
i dunno...weirdJaesun - this is set in your php.ini file
Basically, in order for the server to keep track of a users session, it needs to have a session ID that follows the user. By default, IF the user allows cookies, it will set a cookie on their system. IF they do not, it will automatically add it to all your links (if you had <a href=http://www.htmlforums.com/archive/index.php/"page2.php">page2</a> it will change it to <a href="page2.php?PHPSESSID=whatever">page2</a>) or it will add it to forms as a hidden element (what you saw).
This was, sessions work even for uses that do not allow cookies. When you FIRST visit the site, the server is not sure whether or not you allow cookies, so just to be safe...it assumes you cannot. Then if it turns out you can, it stops altering links and forms, but if cookies are disabled, it continues altering everything for you.to be more specific, it is in php.ini under the [sessions] header. You'll see a few options that affect it:
; Whether to use cookies.
session.use_cookies = 1
; This option enables administrators to make their users invulnerable to
; attacks which involve passing session ids in URLs; defaults to 0.
; session.use_only_cookies = 1
this defaults to 0, and if you were to change this, it would ONLY use cookies (and NOT change links or forms). However, then it would only work with people who allow cookies
; Name of the session (used as cookie name).
session.name = PHPSESSID
if you change this, then the name of the cookie or hidden field will change. If you make it just "ID" for example, the name of the hidden field would just be "ID"
; The URL rewriter will look for URLs in a defined set of HTML tags.
; form/fieldset are special; if you include them here, the rewriter will
; add a hidden <input> field with the info which is otherwise appended
; to URLs. If you want XHTML conformity, remove the form entry.
; Note that all valid entries require a "=", even if no value follows.
url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=fakeentry"
This is what actually does the re-writing of the links and forms.ya, that explains it a little more ...
but i probably dont have access to change those options if i wanted to? or i have to go to my hosting company and have them change it.
but i dont think i need to. it will probably be good to leave it as it is, and let php use cookies or links if it has to.
side note/question:
is that why forums for the most part ,leave it by default to pass by the URL? i see alot of forums do that by default (with the option of you to turn it off) ?well, basically it goes like this:
cookies = more secure
url = more flexible (basically this works for everyone)
I use the combo method...it's secure when it can, but it doesn't turn anyone away. I think it's a good medium.you have to edit the ini file to stop it from adding to the url or the form.
you can also take that url sessionid away in an .htaccess file.
url_rewriter.tags
is the handle. you can also set it with ini_set().
but the main culprit is
session.use_trans_sid
if you disable that then it will stop doing that. by default it is a security hazard and it is disabled. ask your host to change it. if not I think you can still use the htaccess file.
add this to your htaccess file to stop it.
php_flag session.use_trans_sid 0does anyone know if its the same in PHP5?
will i lose any functionality if i have my host change it?
ever since i fixed my code to get my admin sections working, i havent seen it since.
actually, i do see it in one case.
<!-- m --><a class="postlink" href="http://www.whiteazn.com/satworld/admin">http://www.whiteazn.com/satworld/admin</a><!-- m -->
if you go there, and click on the W3C validation link at the bottom, it definately shows it there (as it wont validate as strict) .... it seems to put the Session ID as a hidden field in the form TWICE.
but anyways, if i have it changed, will i lose any functionality (of those people not using cookies, as Aaron stated above)?you will not lose any functionality if it is gone. and I also stated it is a securty problem with it being there.ya, thats what i was wondering.. i remember phpBB having some sort of issue for a little bit when it was first released or something lie thatSection Handling Functions - PHP Manual (<!-- m --><a class="postlink" href="http://www.php.net/manual/en/ref.session.php">http://www.php.net/manual/en/ref.session.php</a><!-- m -->)
URL based session management has additional security risks compared to cookie based session management. Users may send a URL that contains an active session ID to their friends by email or users may save a URL that contains a session ID to their bookmarks and access your site with the same session ID always, for example.
Anyway, Scoutt is right in that it IS a security problem. Say 1 person (a registered user) has sessionID 2345, and has cookies disabled. His links now looks like this: <!-- m --><a class="postlink" href="http://www.site.com/page.php?SESSID=2345">http://www.site.com/page.php?SESSID=2345</a><!-- m -->
Now, he wants his friend to see something, so he sends him that link. When the friend goes to it...it thinks that the friend IS the first person. I mean, he has to be...he has the same session ID!
However, if you do NOT let the URL's be re-written, users that don't allow cookies will NOT be able to use your sessions. That is where you have to make the decision. I'd say that MOST people allow cookies (cookies are allowed by default usually, so users must know to turn them off), but not all. Part of the problem is...I can't find any real statistics on how many people allow/disallow cookies. If you find any, let me know.most users that go to sites that require a login usually except cookies. but like you said, not much data on the issue.
personally I have never ran into a problem with taking the session out of the url/form.well, i can tell you, i for one, block all cookies, and just allow those i want to let in .... seems like a hassle, but thats just meWell, I'd venture to say that #1 - most people don't do that, and #2 - if they are signed up on your site, they'd probably allow the cookie?yes, very true
i did some php code that creates SESSION variables for some member only pages .....
if you go to the login page (and youve never been there before), and looking at the source code, it has this:
<input type="hidden" name="PHPSESSID" value="7abdbb135665f030a9ae786672cb4cbb" />
it seems to just throw that in there on its own (as i obviously didnt put that into the code)
then a couple times, even though i have not been able to reproduce it since, it changes my links from:
a href=http://www.htmlforums.com/archive/index.php/main.php
to:
a href=http://www.htmlforums.com/archive/index.php/main.php?PHPSESSID=7abdbb135665f030a9ae786672cb4cbb
what causes this? anything i need to worry about?
thanksI'm not too used to php, but I don't think you should worry about it. Maybe there's more than one request from different computers so there's more than one session open and it's labelling them to keep them seperate, but don't take my word for it.yeah, PHPSESSID is a variable used to store session specific variables, so when you pass data on that's session specific it's stored in here. So don't worry about it, it's just helpin you out
even though, its not there now that im looking at it and got my member pages up and working? i dunno...weirdJaesun - this is set in your php.ini file
Basically, in order for the server to keep track of a users session, it needs to have a session ID that follows the user. By default, IF the user allows cookies, it will set a cookie on their system. IF they do not, it will automatically add it to all your links (if you had <a href=http://www.htmlforums.com/archive/index.php/"page2.php">page2</a> it will change it to <a href="page2.php?PHPSESSID=whatever">page2</a>) or it will add it to forms as a hidden element (what you saw).
This was, sessions work even for uses that do not allow cookies. When you FIRST visit the site, the server is not sure whether or not you allow cookies, so just to be safe...it assumes you cannot. Then if it turns out you can, it stops altering links and forms, but if cookies are disabled, it continues altering everything for you.to be more specific, it is in php.ini under the [sessions] header. You'll see a few options that affect it:
; Whether to use cookies.
session.use_cookies = 1
; This option enables administrators to make their users invulnerable to
; attacks which involve passing session ids in URLs; defaults to 0.
; session.use_only_cookies = 1
this defaults to 0, and if you were to change this, it would ONLY use cookies (and NOT change links or forms). However, then it would only work with people who allow cookies
; Name of the session (used as cookie name).
session.name = PHPSESSID
if you change this, then the name of the cookie or hidden field will change. If you make it just "ID" for example, the name of the hidden field would just be "ID"
; The URL rewriter will look for URLs in a defined set of HTML tags.
; form/fieldset are special; if you include them here, the rewriter will
; add a hidden <input> field with the info which is otherwise appended
; to URLs. If you want XHTML conformity, remove the form entry.
; Note that all valid entries require a "=", even if no value follows.
url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=fakeentry"
This is what actually does the re-writing of the links and forms.ya, that explains it a little more ...
but i probably dont have access to change those options if i wanted to? or i have to go to my hosting company and have them change it.
but i dont think i need to. it will probably be good to leave it as it is, and let php use cookies or links if it has to.
side note/question:
is that why forums for the most part ,leave it by default to pass by the URL? i see alot of forums do that by default (with the option of you to turn it off) ?well, basically it goes like this:
cookies = more secure
url = more flexible (basically this works for everyone)
I use the combo method...it's secure when it can, but it doesn't turn anyone away. I think it's a good medium.you have to edit the ini file to stop it from adding to the url or the form.
you can also take that url sessionid away in an .htaccess file.
url_rewriter.tags
is the handle. you can also set it with ini_set().
but the main culprit is
session.use_trans_sid
if you disable that then it will stop doing that. by default it is a security hazard and it is disabled. ask your host to change it. if not I think you can still use the htaccess file.
add this to your htaccess file to stop it.
php_flag session.use_trans_sid 0does anyone know if its the same in PHP5?
will i lose any functionality if i have my host change it?
ever since i fixed my code to get my admin sections working, i havent seen it since.
actually, i do see it in one case.
<!-- m --><a class="postlink" href="http://www.whiteazn.com/satworld/admin">http://www.whiteazn.com/satworld/admin</a><!-- m -->
if you go there, and click on the W3C validation link at the bottom, it definately shows it there (as it wont validate as strict) .... it seems to put the Session ID as a hidden field in the form TWICE.
but anyways, if i have it changed, will i lose any functionality (of those people not using cookies, as Aaron stated above)?you will not lose any functionality if it is gone. and I also stated it is a securty problem with it being there.ya, thats what i was wondering.. i remember phpBB having some sort of issue for a little bit when it was first released or something lie thatSection Handling Functions - PHP Manual (<!-- m --><a class="postlink" href="http://www.php.net/manual/en/ref.session.php">http://www.php.net/manual/en/ref.session.php</a><!-- m -->)
URL based session management has additional security risks compared to cookie based session management. Users may send a URL that contains an active session ID to their friends by email or users may save a URL that contains a session ID to their bookmarks and access your site with the same session ID always, for example.
Anyway, Scoutt is right in that it IS a security problem. Say 1 person (a registered user) has sessionID 2345, and has cookies disabled. His links now looks like this: <!-- m --><a class="postlink" href="http://www.site.com/page.php?SESSID=2345">http://www.site.com/page.php?SESSID=2345</a><!-- m -->
Now, he wants his friend to see something, so he sends him that link. When the friend goes to it...it thinks that the friend IS the first person. I mean, he has to be...he has the same session ID!
However, if you do NOT let the URL's be re-written, users that don't allow cookies will NOT be able to use your sessions. That is where you have to make the decision. I'd say that MOST people allow cookies (cookies are allowed by default usually, so users must know to turn them off), but not all. Part of the problem is...I can't find any real statistics on how many people allow/disallow cookies. If you find any, let me know.most users that go to sites that require a login usually except cookies. but like you said, not much data on the issue.
personally I have never ran into a problem with taking the session out of the url/form.well, i can tell you, i for one, block all cookies, and just allow those i want to let in .... seems like a hassle, but thats just meWell, I'd venture to say that #1 - most people don't do that, and #2 - if they are signed up on your site, they'd probably allow the cookie?yes, very true