Webshot unauthorized

[spencergoldade]

Verified license but getting errors from webshot.

Have tried the full HTTPS path and truncated path, but neither elicits a response. Feedback from error messages is unhelpful. Suggest UX improvement for clarity on how the user can affect change. Otherwise just leaves us hanging with an expensive price tag.

[w00fz]

Try https://bugandclaw.com instead

[spencergoldade]

Have tried this, yes. Just attempted again, no luck.

[w00fz]

This seems fine to me. I think that the image is just cached where you are looking at. Check out this: https://www.opengraph.xyz/url/https%3A%2F%2Fbugandclaw.com%2F

[spencergoldade]

Here's from just now attempting to share to Twitter. Something appears lost in translation and the help/error message from Webshot is unhelpful.

Happy to provide anything that may help diagnose! Setup I go, logs, etc.

[w00fz]

I'm confused as to why your SEO images all point to <url>/seomagic-image, that's not the typical webshot URL?

[spencergoldade]

This seems like a good question! I did not know this. Any way I could troubleshoot why that might be?

[spencergoldade]

Here's the full settings. There doesn't appear to be anything harmful in here to share.

[w00fz]

Check your .htaccess to see if perhaps you have some rewrite in place. I don't think this is something SEO Magic does, as a feature, I think there might be something rewriting those URLs and possibly they are cached with that old unauthorized image.

[spencergoldade]

kk! I'm trying to find a standard htaccess for Grav to compare, but it seems pretty standard. I don't recall editing anything in here, nor getting anyone else to.

<IfModule mod_rewrite.c>

RewriteEngine On

## Begin RewriteBase
# If you are getting 500 or 404 errors on subpages, you may have to uncomment the RewriteBase entry
# You should change the '/' to your appropriate subfolder. For example if you have
# your Grav install at the root of your site '/' should work, else it might be something
# along the lines of: RewriteBase /<your_sub_folder>
##

# RewriteBase /

## End - RewriteBase

## Begin - X-Forwarded-Proto
# In some hosted or load balanced environments, SSL negotiation happens upstream.
# In order for Grav to recognize the connection as secure, you need to uncomment
# the following lines.
#
# RewriteCond %{HTTP:X-Forwarded-Proto} https
# RewriteRule .* - [E=HTTPS:on]
#
## End - X-Forwarded-Proto

## Begin - Exploits
# If you experience problems on your site block out the operations listed below
# This attempts to block the most common type of exploit `attempts` to Grav
#
# Block out any script trying to use twig tags in URL.
RewriteCond %{REQUEST_URI} ({{|}}|{%|%}) [OR]
RewriteCond %{QUERY_STRING} ({{|}}|{%25|%25}) [OR]
# Block out any script trying to base64_encode data within the URL.
RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]
# Block out any script that includes a <script> tag in URL.
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
# Block out any script trying to set a PHP GLOBALS variable via URL.
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to modify a _REQUEST variable via URL.
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
# Return 403 Forbidden header and show the content of the root homepage
RewriteRule .* index.php [F]
#
## End - Exploits

## Begin - Index
# If the requested path and file is not /index.php and the request
# has not already been internally rewritten to the index.php script
RewriteCond %{REQUEST_URI} !^/index\.php
# and the requested path and file doesn't directly match a physical file
RewriteCond %{REQUEST_FILENAME} !-f
# and the requested path and file doesn't directly match a physical folder
RewriteCond %{REQUEST_FILENAME} !-d
# internally rewrite the request to the index.php script
RewriteRule .* index.php [L]
## End - Index

## Begin - Security
# Block all direct access for these folders
RewriteRule ^(\.git|cache|bin|logs|backup|webserver-configs|tests)/(.*) error [F]
# Block access to specific file types for these system folders
RewriteRule ^(system|vendor)/(.*)\.(txt|xml|md|html|json|yaml|yml|php|pl|py|cgi|twig|sh|bat)$ error [F]
# Block access to specific file types for these user folders
RewriteRule ^(user)/(.*)\.(txt|md|json|yaml|yml|php|pl|py|cgi|twig|sh|bat)$ error [F]
# Block all direct access to .md files:
RewriteRule \.md$ error [F]
# Block all direct access to files and folders beginning with a dot
RewriteRule (^|/)\.(?!well-known) - [F]
# Block access to specific files in the root folder
RewriteRule ^(LICENSE\.txt|composer\.lock|composer\.json|\.htaccess)$ error [F]
## End - Security

</IfModule>

# Begin - Prevent Browsing and Set Default Resources
Options -Indexes
DirectoryIndex index.php index.html index.htm
# End - Prevent Browsing and Set Default Resources

[w00fz]

Can you try deleting the folder /cache/seo-magic/images ?

[spencergoldade]

Iiiiiinteresting. The Open Graph preview is now working within the Grav admin itself. I had used the manual clear cache and regenerating of images before, so I am curious why that didn't work compared to deleting the folder? The overarching issue seems to persist unless there is a delay on the webshot populating outside of a preview...?

[w00fz]

When you do a simple clear cache, that doesn't actually remove the images. For that to happen you have to do a specific Image Cache Clear (it's in the dropdown list of available cache clear types).

I didn't want for you to clear ALL of your site images though, that's why I suggested to specifically clear that folder.

I think Clear Images / Clear All should do the trick for you next time, however they do also auto-expire after certain amount of time so eventually you would have gotten the right image.

I also realized that the seomagic-image seems to be indeed part of SEO Magic, I must have missed this feature getting implemented. :)

Glad this is sorted!

[spencergoldade]

Just test on WhatsApp, Facebook, and Twitter. Facebook and WhatsApp the preview is popping in but Twitter it's still showing unauthorized (sent to someone new in case there was a caching issue).

[w00fz]

I think it must be the social media caching now. Does it work if you reach the image directly in the browser?

I tried a fresh open graph previewer and appears to be fine for me: https://dnschecker.org/open-graph-preview-generate-metatags.php?query=https%3A%2F%2Fbugandclaw.com%2Fresources%2Fequipment-for-solo-ttrpg-players

[spencergoldade]

I think you may be right!

Just gave it some time and tried again. One page still isn't working but the others slowly are. Also making some new pages just for the sake of testing and seems like I can get them to work in Twitter now. So, I believe it's probably a caching issue now, fingers crossed.

Thank you for your help! I definitely still recommend some improvement to the big scary red messages that were appearing saying Webshot is a pro feature. I was having a Jerry Maguire moment "help me help you, Webshot. Help ME help YOU." :(