Topic: Login fails on first try, successful on second...

[StarredSkies]

Heya folks.

For some reason my users are not able to login the first time. They enter their information the first time on the main page (website.com), but are then redirected back to the index page (website.com/index.php) and are forced to login again (this time being successful). They receive no error messages.

My theme does have the fix from 2.0.14 so it is not that.

This is the same problem as this thread. Based on what users said previously, it may be because my .htaccess file is incorrect. That said, here is that... Am I incorrectly changing it to HTTPS from HTTP and could that be the problem?

Code: [Select]

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

<IfModule mod_security.c>
# Turn off mod_security filtering.
SecFilterEngine Off

# The next part below probably is not needed, but better safe than sorry.
SecFilterScanPOST Off
</IfModule>

php_value display_errors on

php_flag session.use_trans_sid off

php_flag session.use_only_cookies on
Running 2.0.15 still.

[Kindred]

the problem may be http/https or www/non-www

but, yes, basically your htaccess needs to redirect users to the URL that you set in as the base url of your forum

[drewactual]

Code: [Select]

RewriteEngine on
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.-xxxx-.com/$1 [R=301,L]

^ has worked flawlessly for me for a long time on several different sites.  notice the www in the last line- IF your forum's URL's don't use 'www' in the base, don't put it there either.  obviously, change the -xxxx-.com to your URL. 

if this isn't it, i'd be interested in seeing what your host has set up for expires in their httpd.  a lot of times they aren't optimum for 'live' dynamic sites but are for static sites... and there can be a lag for actively contributed content... i had a heckuva time with Etags doing this.

[shawnb61]

Was the forum recently upgraded?  I believe this is normal after a conversion from SMF 1.0.x. 

[Arantor]

Correct, it is normal for the first time a user logins in where it upgrades the security of their password - but it should have a message displaying that.

It isn't clear if this is 'every user, every time they try to log in the first time' or 'only the very first time a user logs in'.

[StarredSkies]

the problem may be http/https or www/non-www

but, yes, basically your htaccess needs to redirect users to the URL that you set in as the base url of your forum

I'm thinking it might be deeper than that? Unless I'm doing this completely wrong... which isn't out of the question.

if this isn't it, i'd be interested in seeing what your host has set up for expires in their httpd.  a lot of times they aren't optimum for 'live' dynamic sites but are for static sites... and there can be a lag for actively contributed content... i had a heckuva time with Etags doing this.

Asking my host right now. Will get back to you when I receive a reply.

Was the forum recently upgraded?  I believe this is normal after a conversion from SMF 1.0.x. 

No. I have only used 2.0.15. New to this, apologies.

It isn't clear if this is 'every user, every time they try to log in the first time' or 'only the very first time a user logs in'.

It's every user, every time they try to log in the first time.


So I used the method from @drewactual and modified it accordingly for my website. I tried a few different methods. Will list below... Needless to say though, we're still on square one.

One: (WWW)

Code: [Select]

RewriteEngine on
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.beastsofbeyond.com/$1 [R=301,L]


Code: [Select]

RewriteEngine on
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.WEBSITE.com/index.php [R=301,L]
When I tried WWW (and with index.php), I received an error that proclaimed "Unable to verify referring url. Please go back and try again." So I concluded at this point my base-url did not include www.

Two: (Non-WWW)

Code: [Select]

RewriteEngine on
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://beastsofbeyond.com/$1 [R=301,L]

Code: [Select]

RewriteEngine on
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://WEBSITE.com/index.php [R=301,L]Would just reroute back to the main index once again. Back to square one...

Three:
Also tried a different method online to see what else could possibly be the problem. Hell, I'll try anything at this point.

Code: [Select]

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteCond %{HTTP_HOST} ^(?:www\.)?(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [L,NE,R=301]But no luck...

I have also tried recreating a redirect within CPanel's redirect area (/ -> /index.php) AND forcing the site to HTTPS through CPanel, but no luck.

[drewactual]

you may be a good candidate to run repair_settings.php and make certain your pages are properly set- www or non, https or http... obviously you'll want the https but choose the www or not accordingly. 

the htaccess forward i provided is the easiest to use and i recommend it.... don't add the /index.php to it, though... just as i presented it.  you don't want any strange behavior out of it and that will ensure you get just that.

i'd be curious to see what else your htaccess holds... specifically for expires and cache. 

can you add a phpinfo.php to your site so we can see your configuration (and if there is some strange caching being done)? also, whatever mods you're running- specifically if any of them use a different login script such as the various social media logins...

[drewactual]

disregard... I see openID is operational on your site.  can you disable it without errors? if so, can you try to do so and see if the issue follows. 

i can tell you from experience, as a for instance, that mod hasn't made the 2.0.14 login form modification which means you have to add it yourself.  it's easy to do, basically adding a single line of code.  we should at least rule that out. 

[StarredSkies]

Ran repair settings, found no problems whatsoever link/directory wise. They were all https and non-www. Some (probably unrelated errors) at the top though.

Notice: Use of undefined constant ‘session - assumed '‘session' in /home/NAME/public_html/Settings.php on line 86

Notice: Use of undefined constant use_only_cookies’ - assumed 'use_only_cookies’' in /home/NAME/public_html/Settings.php on line 86

My .htaccess is now this as follows and nothing more... with your suggestion!

Code: [Select]

RewriteEngine on
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://WEBSITE.com/$1 [R=301,L]

<IfModule mod_security.c>
# Turn off mod_security filtering.
SecFilterEngine Off

# The next part below probably is not needed, but better safe than sorry.
SecFilterScanPOST Off
</IfModule>

php_value display_errors on

php_flag session.use_trans_sid off

php_flag session.use_only_cookies on

Here is the phpinfo.php you asked for. Such a neat lil feature I never knew about, thank you.

Full list of mods:
SMF Post Prefix   2.0.3   
Stop Spammer   2.3.9   
SMFShop   3.3.5   
BBCode with style   1.5.1   
More Genders   1.0.1   
@mention members   1.1.2   
SubAccounts Mod   1.0.1
Bookmarks   2.5   
markItUp! for SMF   0.5.5
Current Signature Mod   1.2   
SMF Staff Page   1.7   
Topics Created And Participated In   2.9   
@mention members   1.1.2      
SMF Staff Page   1.7   
Ignore Topics   2.3   
Posting Template SMFSimple   1.0.3   
Yet Another Spoiler Mod   1.1      
Yet Another YouTube BBCode Tag   4.12   
Ultimate Profile   0.9.1   
Sneaky Editing   1.1      
Member Awards   3.0   
Global Headers Footers   2.1a   
Custom Username Color   1.2   
Avatar on Member List   2.0   
Custom Action Mod
Drafts

Disabled openID. Found no problems.

i can tell you from experience, as a for instance, that mod hasn't made the 2.0.14 login form modification which means you have to add it yourself.  it's easy to do, basically adding a single line of code.  we should at least rule that out.

Which modification to be exact?

[drewactual]

looking at your php(info) and your htaccess, the only thing that jumps out at me is your garbage collection and when you take it out... so, lets rule that out. 

add:

Code: [Select]

php_value session.gc_divisor 100000
php_value session.gc_probability 1

what ^that means and does:  every 1000 'clicks' on your page will result in one session being destroyed... the 'garbage collection', as it's called, is how your server is doing in NOW.... increase that... instead of users facing a 1 : 1000 chance of having to log back in, if you change it to the suggested value (100k / 1) they'll stand a 100k : 1 chance of being logged out as php 'takes out the session's garbage' ... in other words, the opportunity to lose their session is greatly reduced.   it's supposed to be 'random', but, as we've discovered, computers like pattern's and nothing is 'truly' random with them. 

you could also consider changing your gc_maxlife too, by adding:

Code: [Select]

php_value session.gc_maxlifetime 86400

that's in seconds... the session will last that long before being tossed (garbage collected aka 'destroyed').

I DON"T THINK THIS IS YOUR ISSUE.  But, let's get it out of the way all the same as you'll discover your users won't have to see that login page as much... SMF does it's own thing, and the server does it's- all this does is makes sure SMF isn't limited by what the server is doing unbeknownst to SMF... the GC is completely outside SMF where the lifetime of a single session isn't, i don't think. 

openID is fine... i was confusing it in my head with the socialLogin mod, which is a total different animal... forget i mentioned it. 

do you have the box "force cookies to be secured" checked in your 'server settings >cookies and sessions' page?  if not, check it.   

[StarredSkies]

Added those to my htaccess, but like you said, they do not solve the problem at hand (unfortunately). That is VERY helpful though! Thank you!

Oh that's okay! We all forget things... trust me, I know that very well... What did I say again? ;^)
It's nice to see a social login modification though. Having Discord included in the options is quite innovative, especially since most forum roleplays have integrated it.

Yes, force cookies is checked.

[drewactual]

do 'both' of the login options do this?  meaning: if a user clicks on the login BOX in your header to the right of the image, does it only happen there? Or, does it happen both there AND if they click the login at the top of the page?

reason I ask: your modal may not have the the right code/url in the login link.  it may be simply pushing the user to the login page after doing pretty much nothing. 

[drewactual]

basically try logging in with the modal, and then when you arrive at the full login page, instead of logging in, refresh the page and see if you're logged in or not...

[StarredSkies]

Both of the logins do this. In fact... the entire page does this. First time clicking on anything just sends you back to the index instead of taking where you want. Ex: click on staff list -> taken to index... click on board -> taken to index... click on user in stats -> taken to index...  Second attempt work though! Ex: click on staff list -> taken to index -> click on staff list AGAIN -> taken to staff list.

Also tried refreshing. Does not log me in, unfortunately.

[drewactual]

can we see the index.template for your theme? 

[StarredSkies]

Linked the index template for Reseller that we are using, along with the index template to the default curve theme (but I doubt any problem lies there).

[drewactual]

line 252,
search for and replace:

Code: [Select]


<button type="button" class="btn btn-primary" onclick="location.href=\''. $scripturl .'?action=register\'">', $txt['register'] ,'</button>


you've got two ' instead of a ", no cause for the \ escape

with:

Code: [Select]

<button type="button" class="btn btn-primary" onclick="location.href="'. $scripturl .'?action=register">', $txt['register'] ,'</button>


try this instead...formed properly and shouldn't trip the server pre-processing the script out

line 253
search for and replace:

Code: [Select]

<form id="guest_form" action="', $scripturl, '?action=login2" method="post" accept-charset="', $context['character_set'], '" ', empty($context['disable_login_hashing']) ? ' onsubmit="hashLoginPassword(this, \'' . $context['session_id'] . '\');"' : '', '>


another place where characters intro'd and then escaped... which php does a 'huh?' and isn't needed

with:

Code: [Select]

<form id="guest_form" action="', $scripturl, '?action=login2" method="post" accept-charset="', $context['character_set'], '" ', empty($context['disable_login_hashing']) ? ' onsubmit="hashLoginPassword(this, ' . $context['session_id'] . ');"' : '', '>


try this^ got rid of escapes and formed the code ever so slightly differently.

often modern browsers will make 'assumptions' and fix little things... a div not closed, a span or paragraph not closed... a link mostly formed right... i don't know if these little things are your problem, but let's eliminate them, huh?

those little escapes (\) are nice to have when working with JS, but if you're using them within php like that you're going about things in a way that can be done better.  what i'm thinking is the script flipped out and resorted to the index.php and ignored the following descriptors until it had a moment for the browser to come to the rescue and go "this, i think, is what they're asking".

i rec a using a validator to assist you finding these little things... w3c has a good one.

or.. just upload the attached...

[Arantor]

Those escaped quotes are actually important because it’s quoting JavaScript strings inside the HTML inside the PHP... they’re not nice to have, they’re actually mandatory because onclick="location.href=https://domain.com/" isn’t valid JS...

And putting it with double quotes inside double quotes breaks it more, it ends up as onclick="location.href=" with the URL loose inside the tag.

Same problem for the rest and likely not the cause, it looked to me like an https redirect issue.

[drewactual]

this is your issue:

when a user first visits, there is no session so the phpsession is appended to each link... once the user interacts, the session info is removed from the links...

to see this, open a private browser (incognito window) and go to your site... right click view source... check out the links with the phpsession appended... now, while still viewing source, click one of them and the 'view source' from the link you clicked will show that links source- less the sessions appended to the link...

tracking?

to fix it, try adding this line to your htaccess, and right below the closing of the ifmodule.. (/IfModule)... :

Code: [Select]

php_value session.auto_start 1


[Arantor]

You mean the absolutely stock SMF behaviour? (And if you try that suggested hack, it will likely break other things, as that will start sessions before SMF’s session config could load)