Now Viewing: Error 403?
Keep it civil, do not flame or bait other users. If you notice anything illegal or inappropriate being discussed, contact an administrator or moderator.
Quote
Posted on: 10/15/15 02:08AM
That's how it was supposed to be for years. I'm not sure what was causing the check to fail. I'm also not sure what made lozer go and fix it. It could be as simple as him not having noticed it until recently, or there could be some other reason. We have not been informed.
Posted on: 10/15/15 02:26AM
Why is the API disabled now? A third party app I use relied on it...
Posted on: 10/15/15 02:33AM
Our API has been receiving an unusually high level of traffic.
Please note that this is unrelated to the issue causing the site to load slowly for some US users at night.
Please note that this is unrelated to the issue causing the site to load slowly for some US users at night.
Posted on: 10/15/15 02:36AM
Actually even I, from Germany, have been seeing unusual slowness at times.
Posted on: 10/15/15 11:01AM
Jerl said:
The API is disabled for everyone, not just you. This includes tools I've used for moderation purposes.
That level of use is certainly within acceptable levels.
The API is disabled for everyone, not just you. This includes tools I've used for moderation purposes.
That level of use is certainly within acceptable levels.
Ah ok. Cool. Well, thankfully I cache my wallpapers so I have quite a few to pull from until the API returns lol. Thanks so much for offering it in the first place, it's awesome :)
Posted on: 10/15/15 10:47PM
We are working on updating the API to prevent future abuse. It will be some time until this happens though due to me wanting it to be compatible with 0.3's application of access keys. Just waiting on Geltas to commit his working version to the SVN.
Posted on: 10/16/15 07:50AM
Anime boxes is broken by this change also. Worked fine for years.
Posted on: 10/19/15 04:37AM
The danbooru ajax interface is also broken recently. It worked until around a week ago.
Posted on: 10/20/15 02:42PM
What is that "correct referrer" thing ? It isn't specified in the API docs and couldn't find in on other Gelbooru based websites.
Posted on: 10/20/15 09:43PM
Referrers are a part of the HTTP header. Basically, when you follow a link, your browser sends a link to the page you clicked from. Of course, if you didn't follow a link, it doesn't send a referrer. This is standard behavior; unless you disable sending referrers, every website will be able to see what page you came from.
In fact, it does the same thing when you load images in-page, too.
When you request an image, the server checks the referrer to see where you were referred from and blocks it if it's from anywhere outside of Gelbooru. The purpose of this is to prevent direct-linking images on other sites. For example, it stops you from using an image on Gelbooru in your signature on a forum or embedding it on your own webpage.
Additionally, it also means that to share a Gelbooru image, you have to share the post page rather than a direct link, which helps us because it's a lot more likely that they'll stick around and check out tags on the image, which means they're more likely to stick around. By the same token, it ensures the possibility of ad revenue. We don't get any ad revenue unless you load post or search pages.
The unfortunate side-effect is that users who have intentionally (or accidentally) disabled referrers in their browsers will be unable to load images. If this is the case, re-enabling referrers depends on your browser and installed add-ons.
These are sent automatically by your browser, but you will need to manually add it to the request header in your own applications. How you need to do this depends on what language and library you're using.
As for why you aren't seeing it in the docs, that's because it isn't done by Gelbooru code, but rather the we server itself, in this case nginx. This is a standard setting for web servers, so each webmaster is capable of turning it on or off as they please. The other sites running the Gelbooru software that you've seen haven't made the decision to turn it on.
In fact, it does the same thing when you load images in-page, too.
When you request an image, the server checks the referrer to see where you were referred from and blocks it if it's from anywhere outside of Gelbooru. The purpose of this is to prevent direct-linking images on other sites. For example, it stops you from using an image on Gelbooru in your signature on a forum or embedding it on your own webpage.
Additionally, it also means that to share a Gelbooru image, you have to share the post page rather than a direct link, which helps us because it's a lot more likely that they'll stick around and check out tags on the image, which means they're more likely to stick around. By the same token, it ensures the possibility of ad revenue. We don't get any ad revenue unless you load post or search pages.
The unfortunate side-effect is that users who have intentionally (or accidentally) disabled referrers in their browsers will be unable to load images. If this is the case, re-enabling referrers depends on your browser and installed add-ons.
These are sent automatically by your browser, but you will need to manually add it to the request header in your own applications. How you need to do this depends on what language and library you're using.
As for why you aren't seeing it in the docs, that's because it isn't done by Gelbooru code, but rather the we server itself, in this case nginx. This is a standard setting for web servers, so each webmaster is capable of turning it on or off as they please. The other sites running the Gelbooru software that you've seen haven't made the decision to turn it on.
Add Reply