How to resolve PHPSESSID.

Started by recordset, November 27, 2010, 09:02:34 AM

Previous topic - Next topic

DoctorMalboro

Quote from: opensourcelounge on January 14, 2011, 03:09:55 PM
Quote from: IchBin™ on January 14, 2011, 03:00:06 PMThat is why SMF removes the sessionID from the URL after only a couple of page loads. It's initially set for good reason. After you load a couple of more pages SMF no longer needs it set in the URL.
But this may cause of indexing a same page with different URLs by search engine crawlers (one with PHPSESSID and one without ID). And I think Googlebot does not accept cookies/sessions. I don't know whether this thing really create duplicate pages or not :-\.

And then use your .htaccess to rewrite them as pretty URLs...

Arantor

OK, here's the deal.

SMF only adds PHPSESSID in to the URL to preserve session between loads in the cases it can't generate and keep a cookie on your computer. Since search engines didn't used to handle cookies too well, you ended up with PHPSESSID in the URL to keep the session flowing correctly. The session there isn't being used for security purposes, not really, but for tracking what the user (typically a guest) is doing around the forum for the purposes of who's online.

Thing is, there are numerous cases of the session id being in the URL just you don't notice it, because they're not for indexable pages - take a look at the link for marking a board read sometime. That long string of alphanumerics with an = in the middle... that's a session identifier. But there it's not used to indicate the session back to PHP, it's used to validate the session against the cookie to prevent a CSRF attack - that's the difference compared to PHPSESSID, PHPSESSID is there when there's no alternative.

Baby Daisy

Why is the session even put into $_GET in the first place?
あなたは私のお尻にキスするとき、私はそれを愛する

Arantor

In the case of normal sessions (i.e. classic use of PHPSESSID), it's so that you actually persist sessions across multiple requests without cookie support. But that's mostly going back to the dark ages when cookies weren't pretty much *absolutely standard*.

As for putting the SMF-style session into the URL, that's so you prevent CSRF requests, by having the session id be provided separately to the cookie. In theory you could rewrite every instance that uses this into a POST request, but that would entail having even things like the mark boards as read link be a button, as well as the Pages:  1  2  3 thing in some cases being button based rather than link based.

Baby Daisy

So would it be more of a benefit to have those technical abilities built through $_POST than $_GET? Such as instead of feeding board ids through an array delimited in the URL, but through $_POST content and send through just the action itself?

Why doesn't SMF 2.0 do this considering cookie management is far more advanced than it was 10 years ago?
あなたは私のお尻にキスするとき、私はそれを愛する

Arantor

Because SMF 2.0 was started 5 years ago...

Note I didn't get into the real meat of the detail. There are few requests you can make (anywhere) in SMF that use the session checking match between $_GET's copy of the session and what's in the cookie that are data changing. In theory it's supposedly for only low-grade data changing actions, like marking stuff unread/read, but in practice it's also used for things like the quick moderation actions where they are set to be icons. The real bulk of the session check is where it's submitted in POST, and that should be for every single form submission in SMF.

I bet you a lot of the real is look and feel; if you were to put every case where the session is sent in the URL into a POST form, you'd not only have to totally redesign the admin panel (since, for reasons I don't entirely understand, it sends the session identifier into the page on EVERY page in the admin panel even if it doesn't always session check the URL), but redesign every single page in the forum with any sensitivity, which would mean the mark as read/unread links, the quick moderation and plenty more besides - they'd all have to be forms, they'd all have to be processed as such, when using GET is often simpler, and in reality the security factor is not substantially different in that respect - the only difference is really where the session id ends up in the request, it's still PART of the request, just it's in the header rather than the body. (Though being in the request rather than body, it can end up in server logs more readily; it's no more secure against a packet sniffer either way)

The alternative would be to rewrite everything to use AJAX submissions to asynchronously send POST requests on your behalf. It's doable but adds the requirement of Javascript which right now isn't a requirement, but an enhancement (you can do many things in the forum simply without JS, just it's less 'nice')

Dblog

Quote from: Kindred on January 14, 2011, 03:23:13 PM
it does not affect google in any way, because SF 2.0 uses the cannonical tags

how silly !
even canonical urls have phpsessid tag

dantg

Hello!

I have same problem, here's the output from lynx including headers:


HTTP/1.1 200 OK
Date: Thu, 24 Nov 2011 15:34:09 GMT
Server: Apache
Set-Cookie: PHPSESSID=b374f67ac7697da81dd4eefd25ed9958; path=/
Pragma: no-cache
Cache-Control: private
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Last-Modified: Thu, 24 Nov 2011 15:34:09 GMT
Vary: Accept-Encoding,User-Agent
Connection: close
Content-Type: text/html; charset=UTF-8

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
        <title>Indeks</title>
        <meta name="description" content="Forum - Indeks" />
        <link rel="shortcut icon" href="http://www.domain.com/favicon.ico" />
        <link rel="canonical" href="http://www.domain.com/index.php?PHPSESSID=b374f67ac7697da81dd4eefd25ed9958" />

Kindred

??? You have WHAT same problem?

The original post is a code hack (and an incorrect one that that), not a problem

If you are getting a 500 error, then try the code change suggested by Kays...

As for Cblog's comment... he's wrong, as usual.
Слaва
Украинi

Please do not PM, IM or Email me with support questions.  You will get better and faster responses in the support boards.  Thank you.

"Loki is not evil, although he is certainly not a force for good. Loki is... complicated."

Dblog

Quote from: Kindred on November 24, 2011, 11:32:17 AM
As for Cblog's comment... he's wrong, as usual.

try facebook debug tool on any of the urls in this community and see

Kindred

See what?   That Facebook is not parsing canonical correctly? Or that a debug tool from Facebook is silly?
Слaва
Украинi

Please do not PM, IM or Email me with support questions.  You will get better and faster responses in the support boards.  Thank you.

"Loki is not evil, although he is certainly not a force for good. Loki is... complicated."

dantg

Quote from: Kindred on November 24, 2011, 11:32:17 AM
??? You have WHAT same problem?

Giving every time different canonical to googlebot when it opens any page is very bad for indexing unique content by Google:

hxxp:www.domain.com/index.php?PHPSESSID=b374f67ac7697da81dd4eefd25ed9958 [nonactive]

it should be: hxxp:www.domain.com/index.php [nonactive] or even better hxxp:www.domain.com/ [nonactive]

also relative linking to mainpage of SMF should be set to "/" not "/index.php" - but this is not so big problem as above about canonicals

Kindred

you really have no idea what you are talking about, do you?
Слaва
Украинi

Please do not PM, IM or Email me with support questions.  You will get better and faster responses in the support boards.  Thank you.

"Loki is not evil, although he is certainly not a force for good. Loki is... complicated."

dantg

Kindred, I have been doing SEO for over 10 years, and I know what kind of problems not unique canonical can bring. I don't have to use SMF in the future. Just wanted SMF to be even better than it is now, but if you don't want it, then it's not my problem. I feel like you are the masters and we: simple users saying that something is wrong in your job is like smack into your face. But it's not like that, and if you think it's like that it's childishness. End of transmission about this thread from me, it's useless.

Kindred

What I was saying is that we do not give a different canonical to google....


As for index.php versus root...   There is no difference.

(I too have been doing seo and websites, outside of SMF for decades)
Слaва
Украинi

Please do not PM, IM or Email me with support questions.  You will get better and faster responses in the support boards.  Thank you.

"Loki is not evil, although he is certainly not a force for good. Loki is... complicated."

wing

Digging this up from the dead in hope of some help.

On my site I'm getting these PHPSESSIO= things in some links from guests.

On our wordpress site we link (using SSI.php) to the forum directly.
so on this page:
http://www.autos.ca/car-test-drives/test-drive-2015-land-rover-range-rover-evoque-dynamic/

Down by "Reader's Comments" there is a link to the forum, if I'm logged in the forum the link is:
http://www.autos.ca/forum/index.php/topic,91251.0.html?

But if I'm a guest the link is:
http://www.autos.ca/forum/index.php?PHPSESSID=lml7v0bf07av75r9ev1fc8b1i5&/topic,91251.0.html?

The problem is when you click on the second link, instead of the page opening to the thread specifically it just goes to the main forum homepage.... not good.

We recently switched from apache to nginx/php-fpm  We checked all the trans and session variables and tried both ways, disabled cache etc, still having issues.  Any ideas?

Kindred

the phpsessID is inserted for guests. yes. this is as intended.

However, it looks like you are trying to use the so called "SEF" URLS...    don't. Turn that off. It is pointless, confusing and likely to cause issues.
Слaва
Украинi

Please do not PM, IM or Email me with support questions.  You will get better and faster responses in the support boards.  Thank you.

"Loki is not evil, although he is certainly not a force for good. Loki is... complicated."

wing

#37
Thank you for the reply.  I have not turned SEF off.

Hopefully that solves my issue.  I understand the phpsession id is suppose to be and intended to be inserted, but it was / is causing the issue where the links do not work and the user is forwarded to the wrong URL because of it.

Anyways, hopefully turning off SEF fixes that .....

Kindred

http://wiki.simplemachines.org/smf/SMF2.0:Features_and_Options
Search engine friendly URLs - When enabled, queryless URLs are used for forum pages. This means they look like ../index.php/topic,1.0.html instead of ../index.php?topic=1.0. This option was introduced in order to help search engines index forum pages, but there is no longer any reason to use it, as search engines are now capable of indexing both formats. The queryless URL format only works for Apache and Lighttpd.
Слaва
Украинi

Please do not PM, IM or Email me with support questions.  You will get better and faster responses in the support boards.  Thank you.

"Loki is not evil, although he is certainly not a force for good. Loki is... complicated."

Biology Forums

Thanks for the fix, was looking for this everywhere. I even tried using REGEX via .htaccess.

Advertisement: