HTML 4.01 Compliance..

Posted: Wed Oct 11, 2006 2:21 pm

A bit of a nitt, but NukeSentinel seems to be appending &NSNST_Flood=....

any way to make it &NSNST_Flood....

?

Posted: Fri Oct 13, 2006 4:36 pm

There are several ways.
Read this:
http://www.ravenphpscripts.com/postt10404.html

To avoid validation issues try to use & in urls

or use in the .htaccess something like: trans_sid_off

registered · Posted: Sat Oct 14, 2006 8:24 am

hireamerica, are you still seeing the appending with 2.5.2?

Posted: Mon Oct 16, 2006 8:45 am

yes, it's still appending in 2.5.2, and I have Flood turned off, btw.

Point is: running the HTML 4.01 validator, it is seeing '&' instead of '&' as I posted in the first msg here.

While I see "To avoid validation issues try to use & in urls" that is my point...I'm not the one adding it as '&' and I'm asking for it to be '&'.

To the other post about Flood being active even when turned off in NS config...I do want Flood on, and will turn it back on when I can make sure a validator sees &

Posted: Tue Oct 17, 2006 8:24 am

Well, the interesting thing is that it is PHP's session management that is adding that. Not sure what the author can do about that. But, we'll have to wait and see...

Site Admin/Owner Joined: Aug 27, 2002 Posts: 17088

If I'm understanding this correctly, we could output_buffer everything and do a search in the buffered output and replace all & with & disregarding where it already has &

Would someone explain how to reproduce this so I can take a look at it?

Posted: Tue Oct 17, 2006 4:38 pm

Maybe I don't have it right either, but I was under the understanding that PHP is appending it to the GET URL automatically, so I do not believe that it is internal page links. I think the problem is that the search engines do not "allow" cookies, so PHP has to place it on the GET string, and therefore, it gets cached that way.

However, the odd thing is that when I checked Google's cache of my site when this issue was first raised, I did not see the NSNST_FLOOD on any of the links and so why I asked the question that I did.

Posted: Thu Oct 19, 2006 7:16 am

I'm researching this in another context and from what I'm reading so far, PHP will only append the SID to the GET URL if cookies are not active on the user's computer. There is a setting:

session.use_only_cookies

that can be turned on to prevent appending the SID to the GET URL. But, if that's turned on, then if cookies are also not on the session functions won't work at all.

Posted: Thu Oct 19, 2006 7:26 am

And, that is the exact point because I believe most search engines do not work with cookies??? I could be wrong, but if I'm not, you would still want flood blocker to catch the really poor behaving ones right?

Posted: Thu Oct 19, 2006 8:23 am

No, they don´t accept cookies. I did some searches when I had this extreme problem with NukeSentinel 2.5.00 but the Google bot followed and indexed sites with such urls.
I wondered about that. However there are other bots like this:

http://www.ravenphpscripts.com/posts6802-highlight-majestic.html

and they just ignore such links or they acting strange.

Posted: Thu Oct 19, 2006 10:19 am

Does sessions.php in the includes directory do the substitution you are talking about, Montego and/or Raven? Specifically, down in the append_sid and admin_sid functions. That code is getting a little out of my depth, especially jumping into it cold.

It's another topic but the Forums code and (I think it's probably bbtonuke code) use sessions very heavily and store sessions and corresponding IP in a sessions table, then validate that the session id is associated with that IP.

Posted: Fri Oct 20, 2006 6:25 am

fkelly, the answer is "no", it does not do the "substitution". In fact, what I believe phpBB is doing is avoiding the use of PHP sessions, hence why it has its own session table and why it is using sessions.php functions to do the "session management".

NukeSentinel is using PHP sessions for the flood blocker. I am thinking that is being done for reasons of speed. Takes DB calls out of the picture.

Posted: Fri Oct 20, 2006 7:18 am

"Sometimes you get shown the light in the strangest of places if you look at it right". Thanks Montego, I see what you mean now. Interesting too that they attempt to validate the session by checking against at least part of the IP address and all the articles on sessions say don't do that because places like AOL are constantly switching the user's IP addresses.

The whole issue of "speed" is one I'm going to experiment with ... sessions versus DB calls. But that's another thread.

registered · Posted: Fri Oct 20, 2006 11:59 am

phpBB does use PHP sessions, passing the SID to validate against its own sessions table. phpNuke uses cookies, bypassing the session thing completely.

Posted: Fri Oct 20, 2006 6:31 pm

evaders99, I think phpBB is using its own "home grown" pseudo methods of doing "sessions". I can find only the following when I do a search for session_start() within the entire RavenNuke directory structure:

Searching for: session_start()
includes\class.php-captcha.php(4 Cool

: session_start();
includes\gfx.php(62): if( !isset( $_SESSION ) ) { session_start(); }
includes\gfx_check.php(102): if(!isset($_SESSION)) { session_start(); }
includes\nukesentinel.php(94): session_start();
INSTALLATION\installSQL.php(2): session_start();
Found 5 occurrence(s) in 5 file(s)

The first three of these are new with the new captcha system Raven is working on and the other two are NukeSentinel and Installation based. I see nothing within phpBB that is using PHP Sessions. That is why they have sessions.php and use the functions in there.

This is all conjecture, but I'd like to understand better how phpBB uses PHP sessions so that I can learn more about it.

Posted: Sun Oct 22, 2006 4:04 pm

Ah never mind, yes phpBB uses its own code defined in includes/sessions.php
Functions like session_begin - where PHP is session_start

It uses a cookie, or passes an SID. Just the way PHP does