10up
Bypass basic auth or change error message
At this part, the plugin is self-remote-requesting to check if ads.txt is accessible via the plugin filter by confirming X-Ads-Txt-Generator header information. In a success, file_exists property is false.
https://github.com/10up/ads-txt/blob/176d28d9ac3d1af551812d956d2cfc0d655a08d5/inc/admin.php#L547-L589
On front-end part in admin screen, js/admin.js checks if response.file_exist property and display message.
https://github.com/10up/ads-txt/blob/176d28d9ac3d1af551812d956d2cfc0d655a08d5/js/admin.js#L31-L36
Toggle message(therefore static) is here:
https://github.com/10up/ads-txt/blob/176d28d9ac3d1af551812d956d2cfc0d655a08d5/inc/admin.php#L303-L308
By the way, self-remote-request can fail in other case than existing ads.txt.
- Server error (50x)
- WordPress is fully under Basic Auth(e.g. a staging site and this is my case)
- CDN dropping additional header.
To bypassing Basic Auth, you can pass auth credentials for wp_remote_request() from Ajax request header. This saves me, but somehow selfish request, I guess.
So, I request some changes on the plugins.
- Return proper error message(server problem, auth required, and do on)
- Display error messages on front end.
- Check file is really existent(e.g.
file_exists( 'path_to_file' ))
I wish send PR if welcomed. Thanks!
Due to the variety of systems the plugin can run on, I don't think it's possible to switch to a file_exists() checks. The use of a server side HTTP request was added in PR #131 to fix the problems described in issue #48.
If the issue of CDNs stripping the X-Ads-Txt-Generator becomes a common issue, then I think that can be handled in a separate ticket.
I think there are two options to consider in the event the response is not a 200 or 404:
- fail silently: simply don't show the message in the event the response is not one that's expected
- show a notice indicating that the presence or absence of the file is not able to be determined.
@fumikito As you've experienced this issue, which of the two would you find most helpful while using the plugin?
@peterwilsoncc Thanks for the reply!
Reading #131 and #48, they are curious and I've found that the current structure is reasonable. People use WordPress in various situations.
About your 2 solutions, I prefer latter:
show a notice indicating that the presence or absence of the file is not able to be determined.
The problem I've experienced is that the plugin told about the existence of a physical ads.txt, but actually no one.
So, preventing such kind of confusion, changing message satisfies me(and maybe other users)
The message could be...
The plugin could not retrieve the ads.txt file. There may be several reasons for this:
- The ads.txt file is placed on the server. This plugin generates a virtual ads.txt file, but it requires that no physical ads.txt file exists.
- There are special restrictions on server access, such as Basic Authentication or a CDN. In this case, the ads.txt file may be displayed correctly. Please try accessing the ads.txt file from your browser to check if it contains the expected content.
Such kind of an allusion can make up for the situation blow:
If the issue of CDNs stripping the X-Ads-Txt-Generator becomes a common issue, then I think that can be handled in a separate ticket.
Hope my comment helps!