yes, seems fine. I've set the f parameter for emailing members to see if this helps. Other than this, I'm stumped.
Logging In Issues
Collapse
This topic is closed.
X
X
-
-
Well -f parameter won't work when I have save mode disabled. I can't see it being a config issue when I get email. Could be a particular email provider is blocking their email. I'm also thinking this is related to browsers and OS of the member. Something outside vB control.Comment
-
Yes all quite possible, best to find out what browser they are using, if they are using a modern one then you may have a corruption in your DB.
Edit: Have you tried Repair / Optimize Tables?Comment
-
I have had a few reports from our clients about the issue. We work also with integrations, and users with integrations were even more affected. Basically, we found out that the issue was caused by a sudden change in vBulletin 4.0.1 cookie prefix structure. Basically, the developers added a "_" after the cookie prefix, thus effectively changing your old cookie prefix. This, coupled with integrated software that used the old prefix structure seemed to cause problems.
Basically, I reverted the edits done by vB developers in class core to use the old cookie structure, and the issues were all gone.
I am not sure if this applies to everybody in this thread, of course - and mine is obviously just a temporary hack.
Basically, in includes/class_core.php, find:
Code:define('COOKIE_PREFIX', (empty($this->config['Misc']['cookieprefix']) ? 'bb' : $this->config['Misc']['cookieprefix']) . '_');
Code:define('COOKIE_PREFIX', (empty($this->config['Misc']['cookieprefix']) ? 'bb' : $this->config['Misc']['cookieprefix']));
Comment
-
It would be better to report the issue to your third party developers and have them fix their code, rather than "fixing" vb's code.Comment
-
Zachery, that's obvious (and I did use fix referring to our situation, not to the code). But :
1. A change like this should have been reported. There are dozens of integrations using cookies. The change went unannounced (no trace of this in 4.0.1 announcement thread), and as a result, a lot of people are having problems. My 2 cents - a lot of people in this thread are having problems because of this.
2. A change like this should happen only for a good reason, not for code "aesthetics". So, I am just asking for the reason of this change.
In brief, in terms of code this is a small change; in terms of real life usage of vB, this is not a secondary change. Cookies are a fundamental part of a system based on login, and that is marketed as a "framework" upon which users can build their websites. Substantially, with this release, vBulletin is forcing an "hidden" cookie change to all those running vBulletin. Is this a trifle matter, especially if you are running a huge community?
Reporting a change like this is a matter of respect towards third party developers, as well, that benefit from vBulletin, but that also add a lot to its value.Comment
-
I had this problem as well. What I found out thou is that if people has http://sitename.com as there bookmark but the board settings were http://www.sitename.com there would not be able to login. However, when a few of us used the site default it showed us logged in. Not sure if this points to a cookie issue, since a few of us cleared cookies prior with no luck.
i set up redirects in my .htaccess ( 301 )
in my current situation, i can't even log in as administrator, otherwise i can configure AdminCP > Options > Settings > Cookies and HTTP Header Options > Cookie Domain?
what should i do?
reset my .htaccess to revert back the preference to www ?
Comment
-
Have you tried changing the cookie prefix in config.php so that it's not trying to use the older invalid one?Comment
-
widgetinstance 262 (Related Topics) skipped due to lack of content & hide_module_if_empty option.
Comment