• Welcome to Simple Machines Community Forum. Please login or sign up.

No Login possible on fresh installation

Started by Dave J, March 11, 2021, 05:13:30 AM

Previous topic - Next topic

Aleksi "Lex" Kilpinen

March 14, 2021, 07:57:58 AM #40 Last Edit: March 14, 2021, 08:09:59 AM by Aleksi "Lex" Kilpinen
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.
A Finnish Project Manager (Support Specialist)
 Happily running multiple SMF 2.x installations.
  Fooling around with i7-10700 @ 2,90GHz-4.80GHz / 16Gb / RTX-2070 Super / 3840x2160 / Win 10 x64


How you can help SMF

"Before you allow people access to your forum, especially in an administrative position, you must be aware that that person can seriously damage your forum. Therefore, you should only allow people that you trust, implicitly, to have such access." -Douglas

Dave J

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?
All the Quiz info is here

Aleksi "Lex" Kilpinen

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.
A Finnish Project Manager (Support Specialist)
 Happily running multiple SMF 2.x installations.
  Fooling around with i7-10700 @ 2,90GHz-4.80GHz / 16Gb / RTX-2070 Super / 3840x2160 / Win 10 x64


How you can help SMF

"Before you allow people access to your forum, especially in an administrative position, you must be aware that that person can seriously damage your forum. Therefore, you should only allow people that you trust, implicitly, to have such access." -Douglas

shawnb61

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).
Address the process rather than the outcome.  Then, the outcome becomes more likely.   - Fripp

Aleksi "Lex" Kilpinen

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.
A Finnish Project Manager (Support Specialist)
 Happily running multiple SMF 2.x installations.
  Fooling around with i7-10700 @ 2,90GHz-4.80GHz / 16Gb / RTX-2070 Super / 3840x2160 / Win 10 x64


How you can help SMF

"Before you allow people access to your forum, especially in an administrative position, you must be aware that that person can seriously damage your forum. Therefore, you should only allow people that you trust, implicitly, to have such access." -Douglas

Dave J

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?
All the Quiz info is here

Aleksi "Lex" Kilpinen

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.
A Finnish Project Manager (Support Specialist)
 Happily running multiple SMF 2.x installations.
  Fooling around with i7-10700 @ 2,90GHz-4.80GHz / 16Gb / RTX-2070 Super / 3840x2160 / Win 10 x64


How you can help SMF

"Before you allow people access to your forum, especially in an administrative position, you must be aware that that person can seriously damage your forum. Therefore, you should only allow people that you trust, implicitly, to have such access." -Douglas

Dave J

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.
All the Quiz info is here

shawnb61

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>


Address the process rather than the outcome.  Then, the outcome becomes more likely.   - Fripp

Dave J

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.
All the Quiz info is here

Dave J

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.
All the Quiz info is here

Aleksi "Lex" Kilpinen

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?
A Finnish Project Manager (Support Specialist)
 Happily running multiple SMF 2.x installations.
  Fooling around with i7-10700 @ 2,90GHz-4.80GHz / 16Gb / RTX-2070 Super / 3840x2160 / Win 10 x64


How you can help SMF

"Before you allow people access to your forum, especially in an administrative position, you must be aware that that person can seriously damage your forum. Therefore, you should only allow people that you trust, implicitly, to have such access." -Douglas

Dave J

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
All the Quiz info is here

shawnb61

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...

Address the process rather than the outcome.  Then, the outcome becomes more likely.   - Fripp

Dave J

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?
All the Quiz info is here

shawnb61

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...
Address the process rather than the outcome.  Then, the outcome becomes more likely.   - Fripp

shawnb61

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.
Address the process rather than the outcome.  Then, the outcome becomes more likely.   - Fripp

Dave J

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.
All the Quiz info is here

dungeonseeker

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

albertlast

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]);

Advertisement: