News:

Bored?  Looking to kill some time?  Want to chat with other SMF users?  Join us in IRC chat or Discord

Main Menu

Error: Unable to verify referring url. When: Removing Old Posts

Started by David8, January 04, 2011, 02:55:27 PM

Previous topic - Next topic

David8

I am running an SMF 2.0 RC4 system and want to remove old posts from some of my boards.  I get the following error message: "Unable to verify referring url. Please go back and try again."

How do I troubleshoot this?  Or, better, how do I fix it?

kat

Firstly, try emptying your browser's cache and deleting your browser's cookies.

Secondly, try another browser.

If neither of those work, try renaming the cookie at Admin>Server settings.

David8

I tried all three suggestions and none worked.  Same error message.

kat



Any recently installed?

Anything in your error-logs? (Admin>Forum Maintenance).

David8

Other than the report of the error under discussion, there is nothing that looks relevant in the error logs.  I have run all the simple maintenance tasks and my files are all up-to-date. 

Since I have not run this particular task, Remove Old Posts, in a long time, it is hard to give a meaningful answer to the question about mods.  Here is a complete list of what is installed.  The * flags uninstalled mods.


*1.    Admin member list registration date    1.1    [ List Files ] [ Delete ]
2.    Ultimate Profile    0.9.1    [ Uninstall ] [ List Files ] [ Delete ]
*3.    Gender on Memberlist    1.4    [ List Files ] [ Delete ]
*4.    Additional Membergroups on Profile    1.1.1    [ Install Mod ] [ List Files ] [ Delete ]
5.    Default_Membergroup    1.0.1    [ Uninstall ] [ List Files ] [ Delete ]
6.    Board Viewers Mod    1.2.1.1a    [ Uninstall ] [ List Files ] [ Delete ]
7.    Aeva Media    2.10    [ Uninstall ] [ List Files ] [ Delete ]
8.    Last Post On MemberList    1.3    [ Uninstall ] [ List Files ] [ Delete ]
9.    Sitemap    2.2.0    [ Uninstall ] [ List Files ] [ Delete ]
10.    SoLoSMiLeYS    1.0    [ Uninstall ] [ List Files ] [ Delete ]
11.    Stop Spammer    2.3.8    [ Uninstall ] [ List Files ] [ Delete ]
12.    httpBL    2.4    [ Uninstall ] [ List Files ] [ Delete ]
13.    Ad Seller Pro    1.0.7a    [ Uninstall ] [ List Files ] [ Delete ]
14.    Enhancements to purge inactive members    1.0.1    [ Uninstall ] [ List Files ] [ Delete ]
15.    Last Active On MemberList    1.4    [ Uninstall ] [ List Files ] [ Delete ]
16.    TopicCountOnDisplay    2.0 RC4    [ Uninstall ] [ List Files ] [ Delete ]

kat

Quote from: David8 on January 04, 2011, 04:33:54 PM
Other than the report of the error under discussion

What do the logs say, with regard to this, exactly?

That's the clue we'll need, most likely.

Were any of those mods installed, prior to the problem you're having manifesting itself?

David8

I assume you mean the SMF Error Log.  It reads:

Type of error: User
http://southwestcompanions.info/SWC/index.php?action=admin;area=maintain;sa=topics;activity=pruneold
Unable to verify referring url. Please go back and try again

The actual action is to remove posts older than 90 days from a single board.

All the mods were installed before this problem arose.  However,  I have never actually run this procedure before so that does not mean much.  In other words, I have never run it successfully.

kat

Nope.

Sorry, I should've explained better.

If you go to Admin, you'll find "Logs", in the left-hand pane, right at the bottom, under "Maintenance".

David8

I was quoting from All Errors in the Error Log from that area.  None of the other logs mention the problem.

kat

Hmmm...

Well, I'm just about to hit the sack, I'm afraid.

If nobody else has any ideas, I'll get back, to this, first thing in the morning.

David8


kat

This has got to be worth a shot.

In Admin>Server settings>Cookies and Sessions, you'll see:

Enable local storage of cookies
(SSI won't work well with this on.)


and

Use subdomain independent cookies
(turn off local cookies first!)



I can't be much more accurate than to say "Try fiddling around with those", really.

If one's checked, uncheck it and check the other one.

If none are checked, try checking one, then the other.

If they're both checked, we've found your problem. ;)

David8

I have tried all the combinations suggested.  The problem is still there.

Where is the code that is checking URLs and reporting a failure?

Or, help please!

Arantor

Now, this works on an unmodified SMF RC4, so presumably it's something that has been altered elsewhere, and there are two reasons why the verify referring URL error might occur.

1. You have a Pretty URLs type mod that's rewriting action=admin (but that doesn't seem to be the case)
2. You have security software that's not passing the HTTP Referer header through, or your firewall is removing it before it's getting sent to the server. Could be a browser plugin of some kind too.

David8

I doubt it is the browser or a browser addon since I have tested with Chrome, IE and Firefox. 

I also note that the error does NOT occur when I delete inactive members.  One might think that the same or similar verification code would be called by both processes.

And, I just tested with my firewall turned off.  Same problem.

Arantor

No, the verification code is slightly different in the other cases, since the referring action isn't checked in them.

Something is removing the referer in your requests. Running Norton Internet Security?

David8

I am running ZoneAlarm Extreme Security. 

Where is the code that is checking the URL located in the SMF php system?

Arantor


David8

But, as I said, I tested with ZoneAlarm turned off.  Same problem.

And, with ZoneAlarm on it works in my test board.

David8

I think that I have identified the source of the problem.  It seems that the
package Ad Seller Pro 1.0.8 is messing up the URL.

The error message is triggered by code in Security.php at lines 723 to 728 in
definition of function checkSession().  This function is called by function
RemoveOldTopics2() in RemoveTopics.php with the arguments shown:

   checkSession('post', 'admin');

At line 724 checkSession tests to see if the code 'action=admin' is present in
the URL returned by the PHP function $_SESSION['old_url'].  The test fails and
triggers the error 'verify_url_fail'. 

To debug I inserted the following line of code after line 725 in Security.php

      log_error('old_url=[' . $_SESSION['old_url'] . ']');

This code returns the following in the error log:

http://...my board domain.../index.php?action=admin;area=maintain;sa=topics;activity=pruneold
old_url=[http://...my board domain.../index.php?action=adpro;sa=v&id=7&l=2&m=0&t=1297440989]

The second line above shows the problem.  It says 'action=adpro' not 'action=admin'
and the test fails.  It looks like Ad Seller Pro is messing up the old_url.

Now the question is how to fix it.

Arantor

Ask the author. You paid for it, you're entitled to take it back to him to make him fix it.

(I refuse to do anything where vbgamer's paid mods are concerned. Long story, not pleasant.)

vbgamer45

Posted possible fix on my site.

Might impact a lot of mods now that I think about such as enotify or anything else that does another query on that page.

By default only skips the dlattach action.
Community Suite for SMF - Take your forum to the next level built for SMF, Gallery,Store,Classifieds,Downloads,more!

SMFHacks.com -  Paid Modifications for SMF

Mods:
EzPortal - Portal System for SMF
SMF Gallery Pro
SMF Store SMF Classifieds Ad Seller Pro

David8

vbgamer45's patch fixed the problem.  However, I feel that there is a problem with SMF's method of checking security if it can be broken that easily.  The use of the $_SESSION[old_url] variable for verification makes a lot of assumptions about what is going on that, clearly, are not very robust.  In this case it was being changed in an unanticipated way.

Arantor

I feel there's a problem if a mod is doing things it's not supposed to be doing - how is it SMF's fault that it has proper protection written in but that a mod has been written badly (or more accurately, written for 1.1.x and ported to 2.0 because that's how 1.1.x admin system was written, to use first level actions) that breaks existing functionality?

David8

Arantor,

I knew enough to figure out where the problem was.  I do not know enough to have patched it my self. I also am not saying whose programing is at fault here.  Don't know enough about the overall architecture.  It may well be that AdPro is doing things it should not be doing.  I appreciate your help.

David8

Advertisement: