UseBB Community

There is a cookie/session problem in Opera/Konqueror browser which prevents users from registering or logging in to the forum from those browsers when the SEO URLs are used (e.g. forum-1.html).

To check, try on this very forum. I thought it was a cookie/domain problem, but even here the problem exists when I tried to register with Opera 9.01 browser with cookies enabled in the browser.

I can't seem to reproduce this myself. I tested it with Opera 9.02 and Konqueror 3.5.2 on a local setup with friendly URL's and here with the same Opera version.

Any change of being behind a proxy?

I'm not behind a proxy either. I'm just using a normal DSL connection with dynamic ips I tried also in Internet explorer and it doesn't work either. I can neither login and I get a registration error message

Quote

In file panel_register.php on line 282:

E_USER_ERROR - Missing saltcode in session data!

This is most likely due to malfunctioning sessions. Please check UseBB's cookie/session configuration values.

So far only Firefox is working for me (both on my own forum as well as here on usebb.net/community

It works without the SEO URLs, but the URL is ugly with session ids (ugh).

I recieved the same error when using Opera 9.02, not behind a proxy or firewall, direct connection to the internet, signing up for this very site.

The strange thing is that in these browsers even though I've enabled cookies, UseBB doesn't store anything at all. Wondering what this is all about. I tried a couple of other forums and it uses session ids in URLs in other browsers except Firefox. So it's definitely something to do with cookies not being stored instead of sessions in these browsers.

My request is that you can get rid of the ugly session ids in UseBB and make it a cookie only board. After all a lot of browser and session related problems can be handled by cookies alone. A lot of forum software use cookies exclusively to avoid these ugly in-URL session related problems.

Being a PHP developer myself, I can say that mixing cookies and sessions lead to some weird bugs in PHP and I find myself avoiding sessions in favour of cookies which are at least reliable.

Or at least make it an option that as a board owner we can disable the in-URL sessions completely to avoid these bugs.

I've temporarily disabled SEO URLs now on my board, but it does lead to those dreaded session Ids particularly when bots crawl the forum.

It must be something which prevents cookies from being set. One of these cookies contains the session ID that must be present in order to track sessions (required for practically everything, including registering). So it's not a session vs. cookie problem, since a cookie is an essential part of almost any session system.

Quote

My request is that you can get rid of the ugly session ids in UseBB and make it a cookie only board. After all a lot of browser and session related problems can be handled by cookies alone. A lot of forum software use cookies exclusively to avoid these ugly in-URL session related problems.

The session ID's in the URL were added to allow people without cookies to use the board. Of course it doesn't work when friendly URL's are enabled. Anyway, it was not put into the current UseBB 2 codebase, but v1 still has it. By the way, you are having a problem with the cookies, not the in-URL session ID's.

Quote

Being a PHP developer myself, I can say that mixing cookies and sessions lead to some weird bugs in PHP and I find myself avoiding sessions in favour of cookies which are at least reliable.

Sorry, but that doesn't make much sense. A forum system needs a session to keep track of various things. As said, a cookie is therefore used to store the session ID in the browser, so the user can be tracked. Disabling the cookie will lead into the problem you are now having. Ofcourse, unless you only track sessions based on an IP address, but that will create a huge security issue when multiple users from the same IP access the same forum at once.

What concerns the session ID in Google search results, a fix to disable these session ID's for Googlebot was added some time ago, though I don't know if it does its job all the time.

So, I can't really resolve this, since there doesn't seem to be anything wrong in UseBB itself.

What I meant was don't use sessions at all in PHP. Use the cookie (setcookie()) functions directly. Using the session functions you cannot really dictate whether a cookie is set on the user machine or not. You *could* manually use an encrypted string in the cookie alone to store the session info. That was my idea. Instead of using the session management functions.

From a forum owner's point of view, we can then say to other users: "enable cookies in your browser" if they have problems.


The actual bug is this. Currently, in these browsers I mentioned, the in-URL session works so that not using SEO URLs is fine, but even when cookies are enabled on the browser and I use SEO URLs UseBB still does not seem to store session cookies so whenever I try to use the SEO URLs, it fails to track sessions.

Actually I don't know why you've marked this Invalid. Until you can confirm it from other people at least.

Anyway thanks for a great forum software, I just hope you'll investigate this cookie thing because it seems to be a definite issue that session cookies aren't being stored even when the browser has cookies enabled.

In the browsers I mentioned above session cookies aren't getting stored, period.

Quote

What I meant was don't use sessions at all in PHP. Use the cookie (setcookie()) functions directly. [...]

I don't know why it would be bad to use sessions. The difference is that the data is stored in a secure way on the server side, and the client-side only has an ID of the session in order to be tracked. Storing everything in cookies on the client-side (encrypted or not) puts the eventually sensitive data where the user can modify it, or at least make it invalid.

PHP's session functionality isn't all that, it's a very weak designed system which opens a few security holes if you use it without implementing additional tricky security hacks. Maybe it's because of this you're so opposed to sessions, but with the idea of a "session system" there is nothing wrong at all.

To cite from my blog:

Quote

The new session handling mechanism in UseBB 2.0 fixes these problems. This new system is completely custom-made (does not use any of PHP’s default session support), database powered and offers greater flexibility.

This is a custom built session system, which stores the data on the server and uses a cookie with session ID to track the user.

So, the only difference from a client's point of view is that the cookie he receives contains an ID instead of encrypted session data (as you would do it). So there's no reason to be opposed to a session system at all, because for the user there is in fact not a single difference.

Quote

The actual bug is this. Currently, in these browsers I mentioned, the in-URL session works so that not using SEO URLs is fine, but even when cookies are enabled on the browser and I use SEO URLs UseBB still does not seem to store session cookies so whenever I try to use the SEO URLs, it fails to track sessions.

UseBB works like this:
- since it is using PHP's session support, it always tries to set a cookie with the session ID;
- the URL generator checks whether a cookie is present, if not, a session ID is passed in the URL (at least without using friendly URL's);
- resulting from the previous, you always get URL's with a session ID at the first page, because at the first request, when the cookie is sent, it isn't yet sent back to the browser (quite logic since there was only one HTTP request and it just sent the cookie to the browser).

So, whether you use friendly URL's or not, the cookie is always sent, and since you don't seem to receive cookies and friendly URL's do not pass the session ID in the URL, your sessions cannot be tracked, resulting in these problems.

The fact this bug is marked as invalid is because it is not a UseBB problem. I don't know where the problem may be (something on your computer blocking cookies, something between the server and you, or maybe there's a bug in PHP that only affects your host). In any case I tested it with the browsers you mentioned, and I could not reproduce the problem.

So, if anyone can come up with a concrete solution, this bug will remain marked invalid. I'm sorry I can't help you.

Ok, but another user, my friend trickykid also reported the same problem. However, disabling the SEO URLs has temporarily solved it now. But I'd love to use SEO URLs as it makes it much better to index content on the forum.

Looking forward to version 2.0

Oh I just noticed that in the login screen I get this message in place of "remember me" with Opera 9.01

Quote

This feature is disabled because this board can not set or read cookies with your browser.

Yet, I have enabled cookies in opera so I cannot understand why this happens. The same thing also happened in IE 6.0 and in Konqueror.

harishankar wrote

Quote

This feature is disabled because this board can not set or read cookies with your browser.

I get that every once in a while at this forum, I am just using IE 6 only, browser to accept all cookies.

It's normal if you don't have any cookies already set and the login page is the first one you access (no cookies are set at that time).

Dietrich wrote

It's normal if you don't have any cookies already set and the login page is the first one you access (no cookies are set at that time).

Sorry, but it didn't make a difference.

Then I suspect software or anything between the server and the client is blocking cookies, there's no other possibility. Or maybe some people are experiencing strange bugs in PHP itself.

All I can say is, if this problem happens with all PHP scripts using sessions, it would be better to file a bug at http://bugs.php.net/

Yeah, I am now able to login using Opera and IE 6. Strange problem, but I suspect browser related.

Dietrich, thanks for your patience in answering questions.