you can also change the session name in htaccess, this should help with stopping old indexed pages that contain phpsessionid in the url that were indexed before you stopped it.

htaccess value

php_value session.name

ie. php_value session.name MONTY will change the session name from PHPSESSIONID to MONTY

now that would make urls previously with phpsessionid in them, useless..

Whilst that is a neat trick, it won't get rid of the links from search engines, only change the search engine results from (example):

http://www.example.com/modules/mylinks/viewcat.php?cid=3&orderby=dateD&PHPSESSID=f1deb7c154993521b5f459b2b792679c

TO ....

http://www.example.com/modules/mylinks/viewcat.php?cid=3&orderby=dateD&MONTY=f1deb7c154993521b5f459b2b792679c

There have been many good suggestions in this thread, possibly put the 'tips' together somewhere ??

P

true. but if trans_sid is off and session.use_only_cookies is enabled that should force any client to use cookies only.. hence sis will never be passed in the url from then on.

a webcrawler can issue itself a sessionid, but that id is only linked then to an anonymous user, so there is no issue.. the session id should expire after the preset value..

now there's a but.. (but using cookies only, this should solve that issue)

if use cookies only is not enabled you can if you're malicious enough, effectively create a link that you can trick a person into clicking. the url you click contains a redirect to your sites login page, in the redirect the script adds a sid value to the end, of course the malicious user also knows this sid because he is issuing it and not your server.. so effectively an unknowing user can click that link, get directed to your login page, then think oh i have to login.. so he logs in.. of course, he has now logged in using the sid the malicious user issued.

now if the user doesn't physically log out, that malicious user can use that sid and gain access to that account (session hijacking) which is why it is always recommended to physically log out of a site instead of just closing the browser. especially if you have clicked any links to get there.. these kind of hijacks are prevalent in the email scams you get that say you must update your bank details etc.

another reason why auto logins *can* be a security risk, depending on the authentication method of the site and how good the security is already..

but these methods are easily prevented with the right setup and vigilance.. of course XOOPS only uses cookies anyway, so if u don't have a cookie or headers enabled, login will fail.

Very good points there ' m0nty', I'll need a few days to digest it all I think.

Can there be a sticky FAQ about sessions and cookies, put up on the XOOPS site somewhere ? (maybe there already is, I don't know).

m0nty,

Is there a way to use an onclose redirect to automatically logout the user? seems like one method to force the session to expire since we know how end-users never do what you want them to. Maybe a method to cleans the variable pool from a browsers memory would be nice too. I.e. resetting all xoops_vars=default as the user exits.

<disregard this as I've figured a work around for now see post - https://xoops.org/modules/newbb/viewtopic.php?topic_id=42113 >
On another note, I was wondering if it is possible to temporarily make a XOOPS site allow all the login information to be parsed in the address line of a link / shortcut for working out all the different user groups to avoid the constant login in log out hassles. Of course you would want to be careful as to when and where you issue these links / shortcuts as most servers log refferal and redirect information which could then make this information available to those systems. This is just a need to help cut the time constaints to inspect how each user group is going to see content and what they can see more rapidly.

I haven't been able to find any particular info on this other than the xoops_redirect method prevents this type of address line manipulation for autologin methods.

Just wondering .. until I figure something out I'll have to just keep manually logging in/out dozens of times over :|

I am back again on this because phpsshexec is turned on by my hosts and this stops me for using htaccess to set php flag scripts, what other options are there for me, I have created a php.ini file but understand this must be in every directory where i want it to act!?

I was pretty much in balance before I read this thread, now I feel like confusion before he reached wisdom.
And nothing wrong with that, lol.

When this is kinda sorted out, can someone please write here what is the best thing to do, so what must be placed in htaccess / phpini files and what must be the settings in xoops?

I have sessions turned off on my site but I'm getting this error message in PHP debug:Quote:
version 2.0.13.2
common.php seems fine - any idea what might be causing this?

It's only a 'notice' and from the php message, it has ignored the session trying to start, so I assume there is no cause for alarm.

session_start() is only used in one place in that version of XOOPS, and it is the line mentioned, line 177 in /include/common.php

session_destroy() is found in 2 places, line 73 of user.php, when a user logs out:



and line 170 of include/common.php (actually commented out)



I would assume that if people turn on php debug, they will see this 'notice' that you are seeing. But I think any new users for your site are getting redirected, and then a blank page, is that correct ??

So, if that is true, there is cause for concern. I'm rusty on php, but it seems the only way a session is 'destroyed' (and hence the session_start() would cause no errors, is for you to have your own session and session name configured in admin.

Why not turn off php debug, and see if the problem still appears ?

Yes peterr, when you submit the new user registration form, you're redirected to register.php - which is blank. Details are not submitted to the database hence new members can't register right now.
I only turned on PHP Debug AFTER this issue came to my attention. I've now turned it back off and the problem persists.
I was under the impression that blank pages was to do with corrupt or incomplete PHP files so if this is merely a 'notice' and not an error, has anybody any idea what might be causing the blank page?