Re: error: Unable to verify referring url. Please go back and try again.

[landyvlad]

I have been getting the "Unable to verify referring url.Please go back and try again." error when logging in as an admin to access admin functions (That is, I am already logged into the forum proper)

Usually I have to retry 2-3 times before it allows me in.

I've no idea why this is, but would certainly appreciate advice as to how to go about resolving it.  Cheers

[Looking]

That seems to be a common occurrence when using the top header login. What do you get on the login page itself?

[Illori]

https://wiki.simplemachines.org/smf/Login_error_2.0.14

[drewactual]

https://wiki.simplemachines.org/smf/Login_error_2.0.14

i've seen the same thing landy is explaining, and long after the link above was addressed.  for what it's worth, on my install it was related somehow to independent cookies, database driven sessions, and allowing a user to go back to cached pages. 

it happened again when i moved servers and before i migrated the top level domain server- it passed through the 'old' server and to the 'new' one causing issues with sessions being destroyed.

also near the same time i made an adjustment for TTL of workers, so i don't know if that impacted it or not but i've rarely if ever seen it since. 

edited to add:

actually... I may be mistaken.  If my memory (which is admittedly foggy at times) is serving me I 'may' have had to open up SSI.php and change the login script there too, to include the form in the link Illori provided.  I think the MOD Arrantor distributed is the fix for all of it, though.   

[Arantor]

Said mod has since been removed by "Arrantor", just fyi.

[drewactual]

that's a shame, Sir... and apologies for the double tap on R... was their a reason?

[Arantor]

Yes, there were reasons.

[landyvlad]

So is there an official solution / fix?

[GigaWatt]

Modding the theme's files yourself. The modification is not that hard actually. Look at Illori's link . Basically, you have to change this

Code Select Expand

<input type="hidden" name="hash_passwrd" value="" />

to this

Code Select Expand

<input type="hidden" name="hash_passwrd" value="" />
<input type="hidden" name="', $context['session_var'], '" value="', $context['session_id'], '" />

in the theme's index.template.php .

[Kindred]

I think that you all missed the original point.

The error is happening in the admin second password challenge, not the initial login

[GigaWatt]

So, what part of the code is responsible for the second admin password challenge?

[Sir Osis of Liver]

Login.template.php

Code Select Expand



function template_admin_login()



[Arantor]

It isn't template related if it works after 2-3 goes (if it was template related, it wouldn't work at all) seems to be session related more than anything else.

What are you doing when you get the admin login? Are you already in admin doing things?

[Sir Osis of Liver]

It isn't template related if it works after 2-3 goes (if it was template related, it wouldn't work at all) seems to be session related more than anything else.

Yes, and it's nothing to do with the 2.0.14 login session check glitch.

[Bob Perry of Web Presence Consulting]

I believe that I would double check the .htaccess, any user.ini's, any custom php.ini's to be sure that all the session cookies are being stored in the same place. I've run into this sometimes moving from server to server...

[Mareid]

I am having this problem with an add-on domain.  I thought it was related to the add-on domain which I have redirected to newdomain/smf and which works correctly if I spell out the url in the address bar.  If I simply use  newdomain in the address bar, I get the main login screen but when I try to actually log in, I get an error page.  The "guest" login in the upper corner of the page is available.  If I ignore the message, which says "go back and try again, but simply attempt to log in from the "guest" login I do get logged in. 

If I change the login form will this fix the problem? I am using 2.015 without mods.  I have added custom profile fields and a few forums but  I'm just starting.

[drewactual]

my issue was with the session not starting. 

when i use files as the handler it happens a LOT... *I think this has to do with the selection 'allowing return to page' and conflicting prior initiated sessions
when i use memcached as the sessions handler it doesn't happen.
when i made a mistake and tried to write through the wrong port using memcached it happened.  *this was a permissions error at php level NOT SMF

it happened when there was a mis-config of sessions, in other words.

currently w/o conflict and having not seen this in a bit my settings are:
NOT allowing local storage
USING sub-domain independent
forcing secured cookies
database driven sessions
ALLOWING to return to previous page


this is just a thought, but it may behoove to ensure the php.ini settings (or htaccess if that's where you handle it) match the settings SMF is leveraging- insofar as demanding cookies, cookies start auto, require secured, ect... .... the session cookies demanding start being the operative one i'm thinking. 

snip from php.ini :

Code Select Expand


   php_value session.gc_maxlifetime 96000
   php_value session.save_path "127.0.0.1:11211"
   php_value session.save_handler "memcached"
   php_value session.cookie_lifetime "96000"
   php_value session.cookie_secure "1"
   php_value session.entropy_file "XXXXXX"
   php_value session.entropy_length "32"
   php_value session.hash_function "0"
   php_value session.name "XXXXXX"
   php_flag session.use_cookies On
   php_flag session.use_only_cookies On
   php_flag session.use_strict_mode On
   php_flag session.use_trans_sid Off


[Kindred]

I am having this problem with an add-on domain.  I thought it was related to the add-on domain which I have redirected to newdomain/smf and which works correctly if I spell out the url in the address bar.  If I simply use  newdomain in the address bar, I get the main login screen but when I try to actually log in, I get an error page.  The "guest" login in the upper corner of the page is available.  If I ignore the message, which says "go back and try again, but simply attempt to log in from the "guest" login I do get logged in. 

If I change the login form will this fix the problem? I am using 2.015 without mods.  I have added custom profile fields and a few forums but  I'm just starting.

no. your issue is the add-on domain is not a real domain at your host. It is merely a redirect of that add-one domain to your normal domain.
Therefore, there is nothing that you can do to code which will make it work.
Your only option is to add an htaccess forced redirect which forcibly and automatically bounces anyone who goes to add-on-domain.com to your actual-domain.com
This is not a failure in SMF in any way....   

[GigaWatt]

@Mareid: Try changing the cookie name .

[Kindred]

That won't fix it.

I can practically guarantee that the issue is how the server treats addon domains versus real domains

[drewactual]

That won't fix it.

I can practically guarantee that the issue is how the server treats addon domains versus real domains

i don't use subdomains or add on domains whatsoever, and i've seen it.   

it's not a point of arguing with you or trying to defy what your saying- your point is likely valid to the topic offered by the poster with add-on and/or subdomains... but the thing happens for some without that server configuration. 

again, in my case it was related to mis-configured sessions handlers.  using memcache and memcached has to be configured differently, as you no doubt know.  my misconfiguration caused sessions not to be initiated on the admin challenge exclusively and the remedy was to remedy the configuration, and why i suggested investigating that aspect.  using files and writing to disk even properly configured often resulted in this for me.   using memcache or memcached and it rarely happened. using memcache or memcached properly configured and consistent across the server resulted in zero instances of seeing that message. 

also.....

i was using a social login which had several instances of script lacking 'the fix', which i didn't discover until right before i pulled it out of my system.  that also had the 'second challenge' for admin's 'replacement for standard SMF' in it, and it could easily have been causing issues too.   

[Arantor]

True, but in this case it's almost certainly related to the weirdness of addon domains, because while the one error has multiple causes, we tend to explore what's relevant about their specific situation rather than going off what our own personal experience might suggest.

I've seen plenty of weirdness with all the session drivers, including the ones I've written myself, but if I were using the basic and most battle tested choice, I'd be looking at environment ahead of session drivers. Also, I'd probably be Redis but this isn't relevant or useful to anyone else...

[landyvlad]

I still get this error from time to time on 2.0.15 and one a primary domain so subdomains don't enter into it.

[Kindred]

Once again,  what you may encounter is different from what the user specifically describes and I pretty much guarantee that the parked domain is the cause...

And I will also point out that parked dozens are different from subdomains

[landyvlad]

Sorry I wasn't implying that it is not a factor in that user's situation.


Rather, I am also having that problem and it must be something else causing it for me