Danbooru

post/index api returns 503

Posted under General

hi, i have made a program that uses the api (i'm learning cocoa programming and thought it would be a cool thing to learn xml and cocoa using danbooru), but recently i can only get 503 responses from post/index.xml, since it's the same i got from using the browser i resurrected my account, and now the browser goes in, but xml using my program or curl would still send me to 503, i tried making the url like this:

http://danbooru.donmai.us/post/index.xml?tags=mosha&page=1&login=username&password_hash=thesha1saltedhash

but still no luck, i checked the hash against an online calculator and i think my routine to calculate sha1 is ok (even if the sha1 hash on my cookie is different ???), so i wanted to ask if post/index.xml takes login and password, or i'm just not doing it right? or maybe it's supposed to 503 now that you need an account to get in and i should just cease and desist to use the api?

Updated

The password hash in your cookie is what you should put in the password_hash query argument. But even then I regularly get a 503, I think it's just that danbooru is often overloaded and that causes a 503 return. It usually works after a while.

In normal HTML browsing, the 503 is only returned when you don't have an account or aren't logged in. I guess that logic doesn't apply to XML requests. This may be a bug or it may be intentional. Maybe the logic only checks the cookie, which an XML request wouldn't have.

I have the same problem with the IQDB update script. Maybe I should switch to using cookies instead.

This is how it works: if you're not logged in, you'll get a 503 if the site has used too much bandwidth recently. If you are logged in as a member, you'll get a 503 if the server load is too high. If you have a privileged or higher account you should never get 503s.

tl4cu4ch3 said:
i checked the hash against an online calculator and i think my routine to calculate sha1 is ok (even if the sha1 hash on my cookie is different ???)

It should be the same as the hash in your cookie. You must be calculating it wrong. If you're getting this page it means you're not logged in because the hash is incorrect. If you're getting this it means you're logged in but the server is overloaded. Try again in a couple minutes.

piespy said:
I have the same problem with the IQDB update script. Maybe I should switch to using cookies instead.

Does the script use a privileged account? It shouldn't make a difference whether you pass your login credentials in a cookie or as URL parameters.

evazion said:
Does the script use a privileged account? It shouldn't make a difference whether you pass your login credentials in a cookie or as URL parameters.

It uses this account here with the credentials in the URL parameters. I checked that those are right, and it correctly returns my blacklist tags in a cookie. But it still returns a 503 regularly (about 1 in 20 queries, often many times in a row). Like right now, the last 20 queries over the course of an hour returned a 503. And yet it works consistently when I open the same XML request in my browser, with the cookie and with or without credentials in the URL.

thanks for your responses, i'm using sha1 to hash my password (of a free account), i'm hashing it with the salt included at the beginning as the api docs say:choujin-steinerpassword and sending them as parameters, i enabled some debugging and the response i'm getting is the one for users not logged in.
So i think it's the salting i'm using is probably improper.

No, it's "choujin-steiner--password--". For example, my password is "haDukihaDukihaDukisothere", so my password hash is the SHA-1 hash of "choujin-steiner--haDukihaDukihaDukisothere--", which is 6b8ebe6fc79bb212f7ae3b3d800d061f36898a3f.

btw choujin steiner rules

Updated

LMAO, it's always the simplest answer, thank you 0xCCBBA696.
In my defense, everytime i have to read some technical documentation and people use stuff like <your_name_here> they don't mean literally use greater and less than equal signs and underscores, just being extra emphatic about what goes where.
I'll try it --password-- and post back how it went. Thanks again.

And yes, Herr Grimmer is awesome.

1