I have the same issue. 'You were unable to login. Please check your cookie settings.'
I started with installing the latest version from Github and no matter what I did as far as clearing cookies etc and using a newly installed browser it would not let me log in.
I then installed an older version 'smf_2-1-rc2_install' once the install was complete I was able to log in. I then uploaded the 'smf_2-1-rc3_upgrade' and once the upgrade was successfully completed went to log in and again it wouldn't let me.
It's my test site which is in a sub directory of my main site https://www.davejohnson.co.uk/testing/. I have cleared all the cookies and cache from all of my browsers and nothing works. I even used Dolphin browser on my tablet and it still wont let me in.
So you are aware I have recently successfully installed 2.0.18 in the same location with no errors, in fact that's the site I used to reconfigure SMFQuiz, my next mission (with code changes) was to try and get the quiz to work on SMF2.1.
I'm using Hostgator (yes I know what some of you think about it) but I've had no previous issues, apart from self inflicted ones.
PHP ea-php70
Okay, I don't see anything obvious wrong - Try going directly to https://www.*.co.uk/testing/index.php?action=login, do a hard refresh ctrl+F5 and try to login.
Quote from: Aleksi "Lex" Kilpinen on March 11, 2021, 05:32:35 AM
Okay, I don't see anything obvious wrong - Try going directly to https://www.*.co.uk/testing/index.php?action=login, do a hard refresh ctrl+F5 and try to login.
I tried that Lex, see attached for what happened
Interesting. Can you try another browser?
Quote from: Aleksi "Lex" Kilpinen on March 11, 2021, 07:41:13 AM
Interesting. Can you try another browser?
Hi Lex.
Thanks for the replies
I did a fresh install of Chrome, which I've never used before and the results are the same. What I will do is remove the current install and start again with the version from here not the GitHub version. I will give you the password if the issue still remains.
Alright, seems like a sensible next step - I'm gonna split this topic as well, just to keep it separate from the original issue.
After the new install I have tried to register a new member, which went OK until it goes to auto log you in after the sign up process where again it stopped due to the cookie. Looking at the tables it has registered a new member so that process works just not the logging it.
I have just noticed something in the site files via the ftp that there is no 'htaccess file. Should there be one in 2.1?
A .htaccess file isn't a requirement for SMF to work. I'll take a look at your new install.
Thanks.
I have noticed through 'Inspect' on the browser this
Failed to load resource: the server responded with a status of 403 () /testing/index.php?action=login2;sa=check;member=1
Quote from: Aleksi "Lex" Kilpinen on March 11, 2021, 08:23:49 AM
A .htaccess file isn't a requirement for SMF to work. I'll take a look at your new install.
Okay, I can confirm that registration works - and login works until ?action=login2;sa=check;member=X ends up with the error
"You were unable to login. Please check your cookie settings." no matter if I use http:// or https:// - And no SMF cookie is set on the browser, ever. Only a PHP session cookie.
How about you try repair_settings.php and check all your paths, urls just to make sure, and look at your session / cookie settings - How are they set up?
EDIT:
Quote from: Dave J on March 11, 2021, 08:30:18 AM
I have noticed through 'Inspect' on the browser this
Failed to load resource: the server responded with a status of 403 () /testing/index.php?action=login2;sa=check;member=1
That's a good clue!! Do you have access to your server's error log? If you do, take a look at what they tell about that.
Lex,
The server error log just logs this all the time and that's the only error
11-Mar-2021 13:37:35 UTC] PHP Warning: Version warning: Imagick was compiled against Image Magick version 1654 but version 1650 is loaded. Imagick will run but may behave surprisingly in Unknown on line 0
there are 2635 entries for it. Every now and again I just delete the whole log file and then it comes back later starting afresh.
I'll try repair_settings.php and see what that does and let you know.
Ran repair_settings.php and there were a couple of recommendations that were off that I have now selected, see attachments. All other links go to the correct location.
But I still can't log in.
I don't understand how the previous version RC2 works but not RC3 in my head it doesn't make sense. I wonder if I should go back to the previous version and then just start to change templates one by one and see what happens.
I have flagged this topic for the support team and devs, in hopes of getting some more knowledgeable eyes on this.
Quote from: Aleksi "Lex" Kilpinen on March 11, 2021, 08:57:10 AM
I have flagged this topic for the support team and devs, in hopes of getting some more knowledgeable eyes on this.
Thanks very much Lex it's much appreciated. I will leave everything as it is for the time being
Just as a note: 2.1 RC3 download from github last month works fine....
I'll try to update with a fresh copy from github later today and see if I can recreate
Not really sure if Image Magick may cause this kind of errror? From error pasted above, looks like Image Magick version is not compatible with php version installed, right? Can you change php version on your server maybe? And can you post result of phpinfo(); here as well, so we can take a look?
OK, just confirmed that I can not recreate this with a fresh download from github.
Downloaded the Github ZIP
overwrote my existing installation
ran upgrade.php
logged out
logged in
repeated log out/in several times
Something would appear to be odd in the specific setup for your site
have you tried to change your cookie name to something else and see if that helps?
Thanks everyone for your input.
Quote from: Dzonny on March 11, 2021, 09:27:21 AM
Not really sure if Image Magick may cause this kind of errror? From error pasted above, looks like Image Magick version is not compatible with php version installed, right? Can you change php version on your server maybe? And can you post result of phpinfo(); here as well, so we can take a look?
The only way I know how to do that is with the attached pdf.
Quote from: Illori on March 11, 2021, 09:59:13 AM
have you tried to change your cookie name to something else and see if that helps?
I tried changing that from the default to '326' but it's still not working.
Quote from: Kindred on March 11, 2021, 09:43:08 AM
OK, just confirmed that I can not recreate this with a fresh download from github.
Downloaded the Github ZIP
overwrote my existing installation
ran upgrade.php
logged out
logged in
repeated log out/in several times
Something would appear to be odd in the specific setup for your site
What I don't understand Kindred is why SMF2.1RC2 works fine and I can log in, but RC3 doesn't.
The attachment will be temporarily available for team shortly in the Support Team board. Removed from public view by Lex.
I removed the attachment from public view, as a preventative security measure.
Quote from: Dave J on March 11, 2021, 11:00:26 AM
The attachment will be temporarily available for team shortly in the Support Team board. Removed from public view by Lex.
I don't think the Imagick issue is related. I use HostGator & had the Imagick compilation error myself. I opened a ticket, & they responded not to worry, it was just a red herring, & that the new version was backwards compatible. I asked them to suppress the messages, which they did.
The first 3 things I would look at:
1. What is the length of the password_salt field on your members record? Some forums that were originally converted had small fields here, and that caused issues.
2. Are the cookies local? In the settings table, look for the value 'localCookies', if it's not 1, change it to 1. Clear cookies for the site & retry. If your prod site is in another folder on the same site, you may need to do the same to the prod site. Local cookies enable you to have different cookies/sessions for applications in different folders on the same site.
3. We had a bug that caused 403s a few weeks ago. If you have the current GitHub code, that's not it. But if you had downloaded it a while back, please refresh it with current code.
Quote from: shawnb61 on March 11, 2021, 01:13:36 PM
I don't think the Imagick issue is related. I use HostGator & had the Imagick compilation error myself. I opened a ticket, & they responded not to worry, it was just a red herring, & that the new version was backwards compatible. I asked them to suppress the messages, which they did.
The first 3 things I would look at:
1. What is the length of the password_salt field on your members record? Some forums that were originally converted had small fields here, and that caused issues.
2. Are the cookies local? In the settings table, look for the value 'localCookies', if it's not 1, change it to 1. Clear cookies for the site & retry. If your prod site is in another folder on the same site, you may need to do the same to the prod site. Local cookies enable you to have different cookies/sessions for applications in different folders on the same site.
3. We had a bug that caused 403s a few weeks ago. If you have the current GitHub code, that's not it. But if you had downloaded it a while back, please refresh it with current code.
Thanks Shawn
I did check the tables all cookie settings are 1. As far as the length of the password_salt it's 32 characters, all 4 members are the same length
Without going into great detail what's changed fron RC2 to RC3? Because that's where my problem lies.
I'll get back to it again tomorrow.
A brief update.
I have now installed RC3 on another host not affiliated with me at all and I get the same issue. I even used another browser for it too.
Latest GitHub version, or the RC3 download from this site?
Quote from: shawnb61 on March 11, 2021, 02:08:17 PM
Latest GitHub version, or the RC3 download from this site?
RC3 from here. I thought there was a daily update from GitHub to here, so the latest version is always downloaded. If that's not the case I'll change it tomorrow and try again.
Quote from: Dave J on March 11, 2021, 03:06:31 PM
I thought there was a daily update from GitHub to here, so the latest version is always downloaded. If that's not the case I'll change it tomorrow and try again.
No, that's not the case. What gets loaded here is only the released version. What is on GitHub is the current version, including any changes made post-release. If something gets fixed, you either need to get the latest from GitHub or wait for the next release, e.g., RC4.
Quote from: Dave J on March 11, 2021, 01:26:58 PM
Without going into great detail what's changed fron RC2 to RC3? Because that's where my problem lies.
There have been 2184 changes made since RC2...
https://github.com/SimpleMachines/SMF2.1/releases
It is very interesting you are seeing this on a fresh install, too, not just upgrades. To me, this suggests more of a host or base config issue...
A few more things to try:
- A 403 can sometimes be a basic permissions issue. It may help to double-check all the permissions on files & folders.
- I believe we have seen a 403 caused by a mod_security problem. It may help to ask the host to disable mod_security & see if the error goes away.
- It may also help to purge all the sessions. There is code where SMF issues a 403 if it is unhappy with the session. It might help to just delete/purge them all.
If none of the above help, we may need to dive deeper into the exact config & settings...
Check your Settings.php and ensure that $auth_secret is there and populated.
Quote from: SleePy on March 11, 2021, 06:27:42 PM
Check your Settings.php and ensure that $auth_secret is there and populated.
Yes that was there and populated.
Quote from: shawnb61 on March 11, 2021, 06:16:40 PM
Quote from: Dave J on March 11, 2021, 03:06:31 PM
I thought there was a daily update from GitHub to here, so the latest version is always downloaded. If that's not the case I'll change it tomorrow and try again.
No, that's not the case. What gets loaded here is only the released version. What is on GitHub is the current version, including any changes made post-release. If something gets fixed, you either need to get the latest from GitHub or wait for the next release, e.g., RC4.
Quote from: Dave J on March 11, 2021, 01:26:58 PM
Without going into great detail what's changed fron RC2 to RC3? Because that's where my problem lies.
There have been 2184 changes made since RC2...
https://github.com/SimpleMachines/SMF2.1/releases
It is very interesting you are seeing this on a fresh install, too, not just upgrades. To me, this suggests more of a host or base config issue...
A few more things to try:
- A 403 can sometimes be a basic permissions issue. It may help to double-check all the permissions on files & folders.
- I believe we have seen a 403 caused by a mod_security problem. It may help to ask the host to disable mod_security & see if the error goes away.
- It may also help to purge all the sessions. There is code where SMF issues a 403 if it is unhappy with the session. It might help to just delete/purge them all.
If none of the above help, we may need to dive deeper into the exact config & settings...
I hear what you're saying Shawn but it doesn't explain how RC2 works OK and RC3 doesn't. I had mod_security issues before on another host that's why I moved. It's never been an issue before on this host.
I have now wiped that install and I will try the GitHub version one more time. As I said before its not on a live site and I was only going to try the quiz out on it.
Morning all.
Steps today 12.03.21
Delete current 2.1 install complete with tables. Upload 2.1 RC2 and install. On completion log in all ok
Upload to overwrite folders using nightly GitHub folders. (although in retrospect I don't know why I did 'Packages & Smileys')
Packages
Smileys
Sources
Themes
Failed to log. Cookie error again.
Upload previous folders from RC2. Log in all OK. Noticed the error log had multiple errors (see attachment for errors)
Downloaded RC3 upgrade package from SMF. Uploaded upgrade package to overwrite existing files.
Ran 'upgrade.php' all upgrade completed. Log in error with cookie issue again.
Tried to log in from tablet with different browser and different IP still the same error.
Delete RC3 files and tables, re-install RC2. Log in OK. Stopped now.
The current setup is 2.1RC2 which is working fine with no errors. Immediate registration is set so if anyone wants to register and test please feel free to do so.
Quote from: Dave J on March 11, 2021, 01:26:58 PM
As far as the length of the password_salt it's 32 characters, all 4 members are the same length
The password_salt is 255 characters on new installs...
Some old converted DBs have had issues, so we did a fairly recent change (after the RC3 release) to ensure it's OK.
So... Make sure you are using the latest from GH, and have run the upgrader. Double-check that password_salt is 255 after doing so.
If this is the problem, then the RC3 download from simplemachines.org won't fix it. The fix came after that build.
Quote from: shawnb61 on March 13, 2021, 02:47:36 AM
Quote from: Dave J on March 11, 2021, 01:26:58 PM
As far as the length of the password_salt it's 32 characters, all 4 members are the same length
The password_salt is 255 characters on new installs...
Some old converted DBs have had issues, so we did a fairly recent change (after the RC3 release) to ensure it's OK.
So... Make sure you are using the latest from GH, and have run the upgrader. Double-check that password_salt is 255 after doing so.
If this is the problem, then the RC3 download from simplemachines.org won't fix it. The fix came after that build.
Thanks Shawn I'll check it out.
I've downloaded the latest version from GH and installed it. No problems there.
I go to the members table and look at my password_salt and it's still only 32 characters.
I have attached the GH download and a snip of part of the table.
There really didn't seem any reason to run upgrade.php as these are the latest files
Did you actually install it fresh by running the installer? If you didn't, the upgrader is supposed to make the DB changes so yes, there is a reason to run it.
Quote from: Aleksi "Lex" Kilpinen on March 13, 2021, 06:10:40 AM
Did you actually install it fresh by running the installer? If you didn't, the upgrader is supposed to make the DB changes so yes, there is a reason to run it.
Yes Lex. I downloaded the zip file from GH and uploaded that to the folder. Then ran the install.php. I couldn't log in by the way, I didn't mention that in the last post.
I have now re-installed RC2 and looking at the password_salt that is only 4 characters in RC2, see attachment, and I can log in.
I will now try and upgrade RC2 to the GH RC3 and see what happens.
Thanks for confirming. I'll be testing this on my own as well, as now I'm curious.
OK I have now run the upgrade.php to RC3 from RC2 using the files downloaded from GH.
Following the completed upgrade I went straight to the members table and the password_salt is still the same as it was in RC2 only 4 characters and the same ones too, as Shawn said it should upgrade it to 255 characters.
I cannot log in due to the cookie issue again. I have attached another snip showing it's definitely RC3.
I'm going to leave things as they are until I hear from one of you again.
If one of you wants to upload and test install on my host then let me know and I'll give you the FTP login details.
Quote from: Dave J on March 11, 2021, 03:06:31 PM
Quote from: shawnb61 on March 11, 2021, 02:08:17 PM
Latest GitHub version, or the RC3 download from this site?
RC3 from here. I thought there was a daily update from GitHub to here, so the latest version is always downloaded. If that's not the case I'll change it tomorrow and try again.
If using the Nightly Builds from here, Download for nightly(github) smf2.1 (https://www.simplemachines.org/community/index.php?topic=558451.0) then yes they are usually pretty much up to date.
Always pays to unzip the download and check the file called "last_commit_?xxxxxxx" contained within, there's a url in there which lets you compare what you just downloaded to what's on GitHub. Example todays from the nightly builds https://github.com/SimpleMachines/SMF2.1/compare/89c3980...release-2.1 appears to be up to date with what you'd download from GitHub..
Quote from: lurkalot on March 13, 2021, 07:40:01 AM
Quote from: Dave J on March 11, 2021, 03:06:31 PM
Quote from: shawnb61 on March 11, 2021, 02:08:17 PM
Latest GitHub version, or the RC3 download from this site?
RC3 from here. I thought there was a daily update from GitHub to here, so the latest version is always downloaded. If that's not the case I'll change it tomorrow and try again.
"last_commit_?xxxxxxx" contained within
I've been through all the folders etc and there is no file 'last_commit' I did a search also and the only file with 'last' in it is the 'db_last_error' in the 'other' folder.
EDIT: OK I have found it now in the download from here it's not in the download from GH and that is the one I downloaded from GH
Okay, so far - I started with grabbing everything straight from Github yesterday, ran install and everything cool. Got a working install.
Was able to log in, and log out, password field is varchar 64, password salt is varchar 255 (the actual salt is shorter, but that's besides the point).
Guess I'll be working backwords now, and try the RC2 release version next, and upgrade it to that same Github snapshot from yesterday.
Quote from: Aleksi "Lex" Kilpinen on March 14, 2021, 04:41:47 AM
Okay, so far - I started with grabbing everything straight from Github yesterday, ran install and everything cool. Got a working install.
Was able to log in, and log out, password field is varchar 64, password salt is varchar 255 (the actual salt is shorter, but that's besides the point).
Guess I'll be working backwords now, and try the RC2 release version next, and upgrade it to that same Github snapshot from yesterday.
Thanks again Lex it really is much appreciated.
I thought of other things that might affect it, so again I uploaded the latest version to my brothers web host Justhost and tried it again. This time instead of compressing the folder and extracting it with the cPanel file manager I uploaded the file via ftp and it still resulted in the same issue 'check cookies'.
I'm now thinking of getting my old laptop out and using that in case there is something that my desktop is changing when it either zips the folder or during the transfer process.
Not being a scratch coder it's very frustrating for me.
OK, can confirm the salt is only 4 chars on RC2, and login/logout works as expected. The rest of the DB side for password and password salt doesn't seem to be the issue - A fresh RC2 install creates those fields exactly the same as a current build from GH.
Running the upgrade to current GH, and logging in after that, did work and the salt got updated in the DB. No problems logging in or out.
So, my testing did not provide much more information on this - it is most likely something about your specific hosting environment or install.
I do not see that 403 on my test installs though, or any other errors for that matter. This could still be a worthy clue.
Quote from: Aleksi "Lex" Kilpinen on March 14, 2021, 07:57:58 AM
OK, can confirm the salt is only 4 chars on RC2, and login/logout works as expected. The rest of the DB side for password and password salt doesn't seem to be the issue - A fresh RC2 install creates those fields exactly the same as a current build from GH.
Running the upgrade to current GH, and logging in after that, did work and the salt got updated in the DB. No problems logging in or out.
So, my testing did not provide much more information on this - it is most likely something about your specific hosting environment or install.
I do not see that 403 on my test installs though, or any other errors for that matter. This could still be a worthy clue.
Thanks Lex.
I did try my old laptop and the result is the same. I'm beginning to agree with you that it might be the host now, although I did try it on my brothers site with the same result and that's a different host, albeit that Hostgator and JustHost are owned by EIG.
One quick question. Are you testing this on a webhost or on your localhost/PC? The reason I asked is some while ago, I mean years, there was an issue on a live webhost that didn't show up on a localhost.
I have a user.ini in the public_html folder of my main site. I have attached it, do you think this might be an issue?
I'm testing on my VPS. Prefer to do testing on live environments.
That .ini seems to be a local PHP settings -file. In itself it shouldn't be a problem, with a quick look through didn't see anything obvious with the settings either - but to answer that for sure, I would have to read it more carefully.
Quote from: Dave J on March 13, 2021, 06:52:19 AM
OK I have now run the upgrade.php to RC3 from RC2 using the files downloaded from GH.
Following the completed upgrade I went straight to the members table and the password_salt is still the same as it was in RC2 only 4 characters and the same ones too, as Shawn said it should upgrade it to 255 characters.
I cannot log in due to the cookie issue again. I have attached another snip showing it's definitely RC3.
I'm going to leave things as they are until I hear from one of you again.
If one of you wants to upload and test install on my host then let me know and I'll give you the FTP login details.
Note that when downloading source from GitHub, the installs & upgrades require an additional step after refreshing the source files.
When performing an
upgrade from fresh GitHub files, you should copy all 8 files named 'upgrade*.*' from the /other folder to the forum root before running the upgrader.
When performing an
install from fresh GitHub files, you should copy all 3 files named 'install*.*' from the /other folder to the forum root. In addition, you should also copy the Settings.php blank template from /other to the forum root. Then run the installer.
Following these steps, your password_salt should be varchar(255).
Looking at the screenshots from last page, I think it is - The problem isn't the password_salt field length. It's something else.
The short salt within is a probable red herring, without checking I'd guess the contents are actually only updated on login - and without being able to login, it's not updated. This is sadly one thing I didn't look at when I was testing.
Well I have just configured my Synology NAS drive and I've installed RC3 on that and I CAN log in. That was using the nightly update from here, which as Lurkalot says is the same as the GH version. The password_salt is still only showing 32 characters. I have attached a couple of screen shots. It's using MariaDB v5
Does that help?
Yeah, just as I thought - I don't think the password or password_salt fields are at fault here.
I think it is something else, so we really should try to look at what is different between the EIG crapware and the working hosts.
Quote from: Aleksi "Lex" Kilpinen on March 14, 2021, 03:14:42 PM
Yeah, just as I thought - I don't think the password or password_salt fields are at fault here.
I think it is something else, so we really should try to look at what is different between the EIG crapware and the working hosts.
Ok I will leave it with you guys. I can mess around on my pc now to try and configure the quiz.
Thanks for sticking with it.
A random question or two -
- How big is the value in password_salt on the members record for the user who is attempting to log on? 4 or 32?
- Have you looked in the apache error log? Any clues?
My leading theory atm is that it is a mod_security failure. That particular error message comes from ONE place only... It's pretty deep in there, you are actually past setting id & password. It is now checking the cookie, but failing a basic test on your member ID vs the cookie. But it looks like the member ID is being stripped from the POST, something that mod_sec does...
Your host should be able to see that in their logs & disable that particular rule. It may even show up in your apache log.
And a mod_security failure at this point would behave the same for an install as for an upgrade, i.e., it has nothing to do with the migration itself at all. That would also be consistent with what you're seeing.
You may be able to verify by disabling mod_security yourself in your .htaccess file, e.g., something like:
<IfModule mod_security.c>
SecFilterEngine Off
SecFilterScanPOST Off
</IfModule>
Quote from: shawnb61 on March 14, 2021, 07:53:43 PM
A random question or two -
- How big is the value in password_salt on the members record for the user who is attempting to log on? 4 or 32?
It's 32 characters with RC3 and 4 with RC2
Quote from: shawnb61 on March 14, 2021, 07:53:43 PM
- Have you looked in the apache error log? Any clues?
As far as I can see I don't have access to the apache log.
Quote from: shawnb61 on March 14, 2021, 07:53:43 PM
My leading theory atm is that it is a mod_security failure. That particular error message comes from ONE place only... It's pretty deep in there, you are actually past setting id & password. It is now checking the cookie, but failing a basic test on your member ID vs the cookie. But it looks like the member ID is being stripped from the POST, something that mod_sec does...
Your host should be able to see that in their logs & disable that particular rule. It may even show up in your apache log.
And a mod_security failure at this point would behave the same for an install as for an upgrade, i.e., it has nothing to do with the migration itself at all. That would also be consistent with what you're seeing.
OK well I've just had a chat with them and they are convinced it's the cookie settings. I have attached the conversation text from the chat but basically the op said
QuoteI have checked and see that it is not the server end issue, its SMF settings.Can you please off "Use subdomain independent cookies" and check if that works ?
Which one of the columns in the table would relate to that setting?
Quote from: shawnb61 on March 14, 2021, 07:53:43 PM
You may be able to verify by disabling mod_security yourself in your .htaccess file, e.g., something like:
<IfModule mod_security.c>
SecFilterEngine Off
SecFilterScanPOST Off
</IfModule>
If I make that change would I need to reinstall RC3 again or should it work straight away? if it's the latter then it didn't work
What effect would it have if I turned off
all the cookie column settings? I will try anyway but you guys might know if I would make signing in more of an issue.
I've done it...woohoo
Yes I know that seems a little childish but it's been bugging at me for days now.
During tables install a column is added to the 'settings' table with the variable 'globalCookiesDomain' this is what the problem has been. After the install the value in my column was 'co.uk'. When this value is changed to '0' then I can log in to the newly installed RC3.
Once you log in there is an error in the error log. I uninstalled and reinstalled and the error is made at exactly the time you click to visit the forum for the first time. See attachments for all items.
So that's all there is to it. I don't know a way forward for that value not to be set but that's what you guys are good at :)
There is just one other thing which is only related to an error for the 'imagick' error that you mentioned Shawn. If you add the following code to your php.ini or user.ini it should stop the error being reported. It's working for me.
imagick.skip_version_check=1
A final thanks to you all for looking into this it really is much appreciated I know you have better things to do.
Question to the wiser among us, shawnb61 for example - Is that globalCookiesDomain value not actually incorrect? Could this be a bug with .co.uk type of TLDs?
It should be the complete domain name right?
I'm not sure if it's worth noting that the install I did on my NAS drive doesn't have the same variables for cookies. See attached
Les - Yes, we should look at that.
The installer attempts to provide good defaults based on the boardurl. I don't think the upgrader touches those settings. Will take a look. So it's odd it was only a problem after the upgrade.
Glad it's sorted.
Maybe a lesson there in looking at the cookie settings when you're having a cookie problem...
Quote from: shawnb61 on March 15, 2021, 12:01:13 PM
Les - Yes, we should look at that.
The installer attempts to provide good defaults based on the boardurl. I don't think the upgrader touches those settings. Will take a look. So it's odd it was only a problem after the upgrade.
Glad it's sorted.
Maybe a lesson there in looking at the cookie settings when you're having a cookie problem...
Shawn,
Did you see the fix for the 'imagick' errors in my previous post?
Yes, saw that. Helpful.
I have two environments. My local version is properly compiled & doesn't generate an error.
For my hosted environment, I made my host deal with it. They should clean up their environment build. Make 'em earn their pay...
Quote from: Dave J on March 15, 2021, 06:49:31 AM
I'm not sure if it's worth noting that the install I did on my NAS drive doesn't have the same variables for cookies. See attached
The installer will make an attempt at cookie settings for your environment. But they are defaults, & should be reviewed. They will not be the same for every environment.
In short, if it thinks there is a subdomain in use, it will set the 'global' setting to 1, and make an attempt at pulling the domain substring from the boardurl. The idea is to share the cookie across the entire domain, including subdomains (e.g., if you want the cookie to be for all of 'dude.net', not just 'forum.dude.net').
In your case that should probably be 0 (false) and blank, as you aren't using a subdomain. As Lex pointed out, that logic for setting initial values didn't work for you here, it thought 'davejohnson.co.uk' was a subdomain of 'co.uk'...
If your forum is within a subfolder on the host, it will set the 'local' setting to 1. This is especially important if you have multiple forums across multiple folders, and wish the cookies to be kept separate and distinct. In that case, local cookies should be 1 for those forums.
Since your testing forum is in a subfolder, I would set both the production & the test forums to use local, folder-specific, cookies. Otherwise, logging out of one will probably log you out of the other, etc.
But the installer just follows some simple rules to set initial values. It cannot glean your
intent from the boardurl. E.g., maybe you really do want that cookie restricted to 'forum.dude.net', not global. So at the end of the day, you should review those settings & make sure they are what you want.
Thanks for the info.
As it's only a test site and will never be live Shawn I'll leave everything as it is.
As the initial issue is now resolved I'll mark the topic as such, please feel free to unmark it if you need it to stay live.
I've got an identical issue, think I might be able to shed some light on it...
My browser console shows
QuoteCookie "PHPSESSID" will be soon rejected because it has the "SameSite" attribute set to "None" or an invalid value, without the "secure" attribute. To know more about the "SameSite" attribute, read *removed link*
and
QuoteCookie "PHPSESSID" has been rejected for invalid domain. index.php
About the wrong domain,
you could test this change:
Session.php
search for
@ini_set('session.cookie_domain', '.' . $parts[1]);
an replace this with
@ini_set('session.cookie_domain', '.' . $parts[0]);
Quote from: albertlast on April 18, 2021, 02:25:18 AM
About the wrong domain,
you could test this change:
Session.php
search for
@ini_set('session.cookie_domain', '.' . $parts[1]);
an replace this with
@ini_set('session.cookie_domain', '.' . $parts[0]);
Hi, not sure if it has the same effect but I did fix the issue by editing the globalCookies key to 0 in the settings table of the database.
I tried changing the globalCookiesDomain key to 0 first (as suggested earlier) but that didn't work for me. Only once I turn global cookies off could I login.
Edit - I should also add that I did suffer from the same bug as the OP in this thread. My forum URL is dungeonseeker.i234.me (its actually a DDNS domain name) and the default install set the subdomain key to ".i234.me" by default.
Since this is a totally fresh install (that I don't really need for a few weeks anyway) I'm quite happy to give you access to the admin account, files, phpmyadmin account and carte blanche to do anything you like (including a fresh install) if you want to investigate. Just PM me and I'll send you the info.
in your case global cookies doesn't work and shouln't be allowed to enable,
since you provide a high chance to share account data with other services how are using i234.me also as service.
Quote from: albertlast on April 18, 2021, 06:42:39 AM
in your case global cookies doesn't work and shouln't be allowed to enable,
since you provide a high chance to share account data with other services how are using i234.me also as service.
It enabled as part of a default install and the issue is that I then could not log in to make any changes at all.
Yes you're correct. I'm doing a site test run on my Synology NAS, the DDNS is from Synology, its running through Apache 2.4 and there are multiple services running on it. The thing is though, I don't need subdomain enabled cookies at all, I don't care if my other services cannot interact with SMF. I just can't understand why having them enabled caused this issue? All my subdomains are running on private virtual servers anyway.
OK, so after doing another reinstall I worked out that I need to make 2 changes to the database for login to work...
I must change globalCookies to 0 then manualy add localCookies and set it to 1.
Hope this is useful.