Error when clicking Leave a Rating

[GrnEyedDvl]

I don't think anyone has reported it this way yet though I did see a ton of posts about rating errors on Resources.

The problem is that if you have not downloaded the Resource, and you click Leave a Rating, it tells you Ooops! And to check your console for errors. This is misleading. It makes you think there is an actual error, when there is not. Or rather its a user error not a technical error.

If you download the Resource then the problem is fixed, because you can now Leave a Rating.

When you click Leave a Rating and you have NOT downloaded the file, it should tell you that you have not downloaded the file. Not give you an erroneous error.

 

[GrnEyedDvl]

Per page vs per code = same thing the way I was meaning it. Sorry if I confused you there.

I think when recursive_error_pages =on that nginx is trapping the error on XenForo earlier than it is trapping the error on vBulletin. On vBulletin it makes it to the vBulletin error message. On XenForo it does not, so it kicks back to the generic Oops message. I am pretty weak with php so I could not make a good guess as to why.

What I meant to say is that recursive_error_pages is either on or off for all errors. Once it traps an error then it has to decide what to do with it. Somewhere its passing that back to XenForo so that XenForo knows to give the generic Ooops message.

I will take a shot at removing the 403 page location but I don't think that will do it. That page never displays so I don't think it makes it that far.

 

[Jeremy P]

The exact configuration you want is a little hard for me to pin down, but recursive_error_pages is valid inside http, server, and location blocks per the nginx documentation: https://nginx.org/en/docs/http/ngx_http_core_module.html#recursive_error_pages

This means you can set it per-host (or even per-subdirectory/location). You can default it to on globally and turn it off for XenForo, or vice-versa.

I will take a shot at removing the 403 page location but I don't think that will do it. That page never displays so I don't think it makes it that far.

It's a bit confusing because XenForo intercepted it client-side with JavaScript (because we try to open the rating page in an overlay), but the error you saw in the console was actually that page:

Post in thread 'Error when clicking Leave a Rating'

Apr 7, 2025

On mine? Yes, but it makes no sense. Its a 403 forbidden to an unspecified file

            <h1>ERROR 403 - Forbidden!</h1>
        </div>
        <div id="content">
            <h2>The following error occurred:</h2>
            <p>You are not permitted to access the requested URL.</p>
            <P>Please contact the <!--WEBMASTER//-->webmaster<!--WEBMASTER//--> with any queries.</p>
        </div>

• GrnEyedDvl

You can likely see it by visiting the URL directly. You can right click the rating button and open the link in a new tab to avoid XF trying to open it in an overlay.

 

[GrnEyedDvl]

Ok I was wrong, this totally surprised me. Commenting out that line did work.

But that is a bandaid not a real solution. Anyone on shared hosting may or may not be able to edit this. And anytime they change a config in a hosting panel that creates a vhost file by script this will get over written.

        error_page 400 /error/400.html;       
        error_page 401 /error/401.html;
       # error_page 403 /error/403.html;
        error_page 404 /error/404.html;       
        error_page 405 /error/405.html;
        error_page 500 /error/500.html;       
        error_page 502 /error/502.html;       
        error_page 503 /error/503.html;
        recursive_error_pages on;

Anyways, thanks for the time. And now at least you know what to tell other people.

On the suggestion side I suggest XenForo does not even show the Leave a Rating button unless someone has downloaded the file. That is tracked already in some stats isn't it? If I think of a more elegant solution I will post it.

This means you can set it for one host (or even a subdirectory/location). You can default it to on globally and turn it off for XenForo, or vice-versa.

Its on or off per vhost.

 

[Jeremy P]

On the suggestion side I suggest XenForo does not even show the Leave a Rating button unless someone has downloaded the file. That is tracked already in some stats isn't it? If I think of a more elegant solution I will post it.

That's certainly a valid suggestion and would address this specific case, but there are many, many cases where we return a 403 response. Any time you try to visit a page you don't have permission to view, you will receive a 403 response with a log-in form, and this pattern is prevalent among many other web applications, including vBulletin.

While I can certainly see the use for 500 (a genuine unexpected error, like MySQL crashes) or 502 (PHP-FPM crashing), we expect to handle 4xx (and 503 when the board is turned off in settings) within XenForo. Web servers intercepting those specifically is something that has only come up a handful of times over the years and I can't recall a time it hasn't been able to be changed, even on shared hosts.

 

[GrnEyedDvl]

That's certainly a valid suggestion and would address this specific case, but there are many, many cases where we return a 403 response. Any time you try to visit a page you don't have permission to view, you will receive a 403 response with a log-in form, and this pattern is pervasive among many other web applications.

While I can certainly see the use for 500 (a genuine unexpected error, like MySQL crashes) or 502 (PHP-FPM crashing), we expect to handle 4xx (and 503 when the board is turned off in settings) within XenForo. Web servers intercepting those specifically is something that has only come up a handful of times over the years.

I am about to show my age here! For decades now I have been telling people that words have real definitions. I quit a fairly large company over stuff like this. I am not a php guy, but I am very fluent in a few other languages even though by trade I am a networking/Active Directory guy.

Words have meanings. When people start calling something an error when it's actually expected behavior it leads to problems like this. It's not unexpected for someone to click a link to something they do not have permission to see. You expect it to happen, which is why you bother to create a page that tells me I cannot rate something unless I have downloaded it.

Having that spit out as an error is the wrong way to go in my opinion, even though its pervasive in the industry with all sorts of things. It leads you down the wrong path. But doing the way its being done is the path of least resistance as far as coding time goes, so this is how its done.

 

[Jeremy P]

I understand debugging this issue was frustrating, and I may not be able to change your mind, but we return these codes precisely because we care to get things right and truly believe it is the correct and expected behavior per the official HTTP specification.

Only 5xx codes are true server-level errors, and you can intercept those from XenForo without much issue. However 4xx are application-level errors. The alternative is to lie and send a 200 response instead, which would be a violation of the specification and cause errors downstream for things like cache servers, web crawlers, and beyond. There's not much different we can really do here.

 

[GrnEyedDvl]

I understand debugging this issue was frustrating, and I may not be able to change your mind, but we return these codes precisely because we care to get things right and truly believe it is the correct and expected behavior per the official HTTP specification.

Only 5xx codes are true server-level errors, and you can intercept those from XenForo without much issue. However 4xx are application-level errors and if we lied and sent 200 instead then it would be a violation of the specification and cause errors downstream for things like cache servers, web crawlers, and beyond. Beyond that, there's not much different we can really do here.

Oh I will almost totally disagree with that, but this might be a conversation we have in another thread.

You do not have to throw it as an error at all. The reason you do is that when you are bug testing is it's easier to catch that way, and then you code behind it. But once you do catch it, you no longer have to call it an error.

You now know where it's going to happen at. So instead of coding after the error, step in before it's an error and point to a different place.

You know that if I click Leave a Rating and have not downloaded the file that it's going to throw a 403. So perform that check instead of waiting for the 403 to appear and then having a procedure to handle it.

It's mostly the same code either way, just rearrange it. Currently it throws a 403 and goes to find out why. As you say, there are many 403 errors. Every time one of them happens you have a procedure to handle it, if I am reading what you say correctly. So it goes something like this.

Click Rating
Somehere in here its already checking if the download has happened anyways.
Get 403
Passes that to an error check function. What is the reason for this 403?
403 came from this procedure.
Procedure checks to see if this was downloaded.
No download
Ok, show this message.

Just skip all that and check up front whether or not it was downloaded.

Click Rating
Check if has been downloaded
If no, show message.
If yes, open rating page.

 

[Jeremy P]

As I've already conceded, it's not the hiding of the button that I necessarily disagree with. We already hide most UI elements that would otherwise return a 403 response.

It's that 4xx responses are, by definition, for errors which are usually determined by the underlying application and communicated back through the the web server to the browser, and there's no real way around that. We don't expect them to be intercepted and that's unlikely to change.

 

[GrnEyedDvl]

I hear you. And I won't take more of your time tonight after this post. Unless you want to discuss the philosophical aspect of coding someplace else.

Back in 1994-95, Visual Basic 4 had just come out and it had this powerful new feature. On Error - Try. This was a step up from On Error Resume. And it led to the poor programming practices that have now become accepted dogma, like the ones you are talking about. It's now common to accept errors as inevitable instead of preventing them. To the point that we call things an error even when they are not.

Now remember, this was wayyy before php. Or really even interactive html. The internet was taking its first breaths. I called it lazy coding back then, and still do. If you trap an error, fix the error. But that is not the way things are done most of the time.

We have a fundamental difference of opinion on what the word "error" means. To me an error is something that went wrong that you didn't expect to go wrong.

Anyways, have a good night.

 

[Jeremy P]

If it helps at all, we do differentiate between problems we can anticipate (like clients taking an unexpected action or providing unexpected input), which are generally 4xx codes (if it helps not to call them errors), and problems we can't anticipate (like the database crashing), which are generally 5xx codes.

These particular response codes are really information for the client making the request (browser) rather than having much internal use to the application itself.

Maybe that should be an option:

Allow Ratings without Download?

Last thing, I promise There is an option for this in case you don't like it:

 

[GrnEyedDvl]

Last thing, I promise There is an option for this in case you don't like it:

Oh cool. Is that set by default? I do not remember setting it, but mine is set.

Almost the last thing, but since we are talking. I do not remember seeing that option, but possibly I did. But I have noticed that some of the options are a bit disorganized. It's not a huge issue, but a couple of things did pop out at me when I first went through them before I even installed the add-ons.

Anonymize IP addresses for Google Analytics - This one is in two places.

Amincp > Options > SEO Options > Almost the last entry on the page.
Admincp > Options > Statistics and Metrics > Second item

Presumably if you tick it in one spot then the other should have it as well, but I have not tested it. The same with some of the user options.

Admincp > Options> User Registration
Admincp > Options > User Options

Name change options are in both. There are a few more. If you ever get more granular with Admin permissions this could be an issue if there are settings in multiple places and you deny one section and allow another, and both have it. And there are some things that should be more granular: like setting conjobs vs triggers, anything involving a file path, cache settings, a few more. Not all admins are equal, especially on the technical side of things.

It appears that everything under Options is controlled by one permission, Manage Options. Yet there is a permission called Manage Resources. So does that control the Resource Manager settings under Options as well as the ability to manage Categories? It isn't clear and I haven't tested it.

 

[Jeremy P]

Is that set by default?

Yeah.

Presumably if you tick it in one spot then the other should have it as well, but I have not tested it. The same with some of the user options.

One option can appear in multiple groups by design to help reduce the need to hunt around for them (though it's almost always easiest to just use the quick-search at the top right). The option value will be the same regardless of what group you're looking at.

It appears that everything under Options is controlled by one permission, Manage Options. Yet there is a permission called Manage Resources. So does that control the Resource Manager settings under Options as well as the ability to manage Categories? It isn't clear and I haven't tested it.

The ability to edit options is all or nothing. The "Manage resources" permission only controls access to the pages under the "Resources" heading in the navigation (ie. managing categories and that sort of thing).