Topic: API login always false

Can somebody help me please? For a project I am making, I try to log in into the API with my username and password and it just doesn't let me. I always get a {"success":false} response and I don't know why.
This is the general code I used to try log in:

String userName = getUsernameInput();
String password = getPasswordInput();

String passwordHashResponseJSON = sendRequest(RequestType.POST, "https://e621.net/user/login.json?name=" + userName + "&password=" + password);

//This creates an object that contains the attributes from the JSON
Object data = fromJSON(passwordHashResponseJSON);

//Then I login
String logInSuccess = getRequest(Request.POST, "https://e621.net/user/login.json?login=" + data.name + "&password_hash=" + data.password_hash);

screen.output(logInSuccess);

The output is always

{"success":false}

Why does that happen? I know I am probably doing this all wrong but still, that is why I need your help, so please, tell me what am I doing wrong...

login.json just gets you the pwhash when given the username + password.. so "login.json" is a bit of a misnomer, "apikey.json" would be a bit more accurate... login doesn't work like that, it isn't "sticky" (in the way it might appear to be sticky when you login via a browser). You get the pwhash once (when your program starts up, say), then you send the username and pwhash as part of the POST parameters for any API call that requires login.
Read the 'logging in' section of API help closely, it tells you this.

I don't know for sure, but probably the success=false is just because you are sending login.json bad input the second time (it wants username and password, but you give it username and pwhash).

You do not login like you do in the browser.
When you want to do something that requires login you send username and passwordhash alongside the data.

Like:
/post/create.json

post[tags]
post[file]
post[rating]
post[source]
username
passwordhash

AoBird said:
You do not login like you do in the browser.
When you want to do something that requires login you send username and passwordhash alongside the data.

Like:
/post/create.json

post[tags]
post[file]
post[rating]
post[source]
username
passwordhash

Oh... Well thank you Birb! And now that I think about it I should had sounded dumb. Anyway, at least now I know. Thanks again! ^^

savageorange said:
login.json just gets you the pwhash when given the username + password.. so "login.json" is a bit of a misnomer, "apikey.json" would be a bit more accurate... login doesn't work like that, it isn't "sticky" (in the way it might appear to be sticky when you login via a browser). You get the pwhash once (when your program starts up, say), then you send the username and pwhash as part of the POST parameters for any API call that requires login.
Read the 'logging in' section of API help closely, it tells you this.

I don't know for sure, but probably the success=false is just because you are sending login.json bad input the second time (it wants username and password, but you give it username and pwhash).

And just a little question too, can I only get the pwhash from the browser or can I do it with a request too?

Alastair_Rayls said:
And just a little question too, can I only get the pwhash from the browser or can I do it with a request too?

Your OP is pwhash request.
enter username and password and you get hash.

Yeah, that. Your first 'login.json' request was correct and that's how you should normally get pwhash

savageorange said:
Yeah, that. Your first 'login.json' request was correct and that's how you should normally get pwhash

It should be good, but for some reason I get a 422 response. It says that the resource is locked. I don't get why though. I made a simple jquery call in the console and it told me that the CORS header 'Acces-Control-Allow-Origin' was missing. I think it is a Cross Origin Error so I used some jsonp to try to solve it, adding the callback paramrter in the url, but I still get the same response code. Do you have any idea why that is?

No experience with JSONP, sorry; it looks straightforward to me but I shouldn't guess.

However regarding HTTP headers such as CORS, this link seems to imply that setting 'Access-Control-Allow-Origin' on the client side isn't necessarily valid or sensible, only on the server side.

What you have said about JQuery is ambiguous (partly because I have no experience with JQuery); it's not clear whether it is the website itself reporting this or some JQuery request-analysis tool.

Have you compared your results to the result of using wget or curl for the same thing? They both can give a lot of information about what is going on with HTTP communication.

EDIT: Here's my results (with some redaction of password).

Command was (approximately) wget --user-agent 'tester 0.3' 'https://e621.net/user/login.json?username=savageorange&password=XXXXX' -O /tmp/pow.json

--2018-11-10 14:05:58--  https://e621.net/user/login.json?username=savageorange&password=XXXXXX
Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
Resolving e621.net (e621.net)... 104.24.11.70, 104.24.10.70, 2606:4700:20::6818:a46, ...
Connecting to e621.net (e621.net)|104.24.11.70|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 20 [application/json]
Saving to: ‘/tmp/pow.json’

/tmp/pow.json                                100%[=============================================================================================>]      20  --.-KB/s    in 0s      

2018-11-10 14:05:58 (2.68 MB/s) - ‘/tmp/pow.json’ saved [20/20]

The json output is the same {"success": "failed"} that you were getting, but the status is normal (200). So I dunno what to make of that.

Alastair_Rayls said:
It should be good, but for some reason I get a 422 response. It says that the resource is locked. I don't get why though. I made a simple jquery call in the console and it told me that the CORS header 'Acces-Control-Allow-Origin' was missing. I think it is a Cross Origin Error so I used some jsonp to try to solve it, adding the callback paramrter in the url, but I still get the same response code. Do you have any idea why that is?

From my own experience when working with the API:

Since you said you're using Java, I assume you made the jQuery request for testing purposes. You need to make the request from the tab where e621.net is open. If you are on any other domain or protocol (like file://), your requests are going to fail. Also, JSONP requests that require authentication don't work (they would need a X-Requested-With: XMLHttpRequest header).

Does your request have user agent?

^ Making a request with no User-Agent normally returns 403 Forbidden on e621, though, not 422.

savageorange said:
The json output is the same {"success": "failed"} that you were getting, but the status is normal (200). So I dunno what to make of that.

You are using a field named username instead of name so it will fail to look up the user and authenticate you.

To the OP:

Per the API page, you get the API key using the username and password and calling /user/login.json, if the user has no API key, the login fails. If the parameters are incorrect, the request fails. If the password is incorrect the request fails. This is as intended. Once you have the API key then you provide it with future requests, but you don't need to login again.

For everyone trying to use javascript cross origin:
e621 doesn't really encourage embedding and creating third party interfaces for the site. They don't display ads, and they often don't take into regards the cost of the requests they make, how frequently they make them, and many other factors. So the CORS headers not being enabled isn't really a mistake, but to encourage third parties working in JS to stick to things that are read only, and to focus on areas that are lower impact.

KiraNoot said:
You are using a field named username instead of name so it will fail to look up the user and authenticate you.

Ha. Same mistake you've corrected me on before, IIRC. Sorry.
Tested with this correction (both wget and curl), works ok (200 OK, json with 'name' and 'password_hash' fields returned)

curl -v seems to be better for debugging requests than wget:

curl -vA 'tester 0.3' 'https://e621.net/user/login.json?name=savageorange&password='(string escape --style url "$PASS") -o /tmp/pow.json (fish shell. If I was stuck with bash escaping would probably be some inelegant shell-out to python urllib.parse.quote function, but string escaping is a builtin in fish)

->

Trying 104.24.11.70...
* TCP_NODELAY set
* Connected to e621.net (104.24.11.70) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.3 (IN), TLS handshake, [no content] (0):
{ [1 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [15 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [3701 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [79 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, [no content] (0):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [52 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: OU=Domain Control Validated; OU=PositiveSSL Multi-Domain; CN=ssl379398.cloudflaressl.com
*  start date: Oct 30 00:00:00 2018 GMT
*  expire date: May  8 23:59:59 2019 GMT
*  subjectAltName: host "e621.net" matched cert's "e621.net"
*  issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO ECC Domain Validation Secure Server CA 2
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
} [5 bytes data]
* TLSv1.3 (OUT), TLS app data, [no content] (0):
} [1 bytes data]
* TLSv1.3 (OUT), TLS app data, [no content] (0):
} [1 bytes data]
* TLSv1.3 (OUT), TLS app data, [no content] (0):
} [1 bytes data]
* Using Stream ID: 1 (easy handle 0x55adedff4890)
} [5 bytes data]
* TLSv1.3 (OUT), TLS app data, [no content] (0):
} [1 bytes data]
> GET /user/login.json?name=savageorange&password=XXXXX HTTP/2
> Host: e621.net
> User-Agent: tester 0.3
> Accept: */*
> 
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, [no content] (0):
{ [1 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [230 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [230 bytes data]
* TLSv1.3 (IN), TLS app data, [no content] (0):
{ [1 bytes data]
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
} [5 bytes data]
* TLSv1.3 (OUT), TLS app data, [no content] (0):
} [1 bytes data]
* TLSv1.3 (IN), TLS app data, [no content] (0):
{ [1 bytes data]
* TLSv1.3 (IN), TLS app data, [no content] (0):
{ [1 bytes data]
< HTTP/2 200 
< date: Sun, 11 Nov 2018 02:58:16 GMT
< content-type: application/json; charset=utf-8
< content-length: 74
< set-cookie: __cfduid=XXXX; expires=Mon, 11-Nov-19 02:58:16 GMT; path=/; domain=.e621.net; HttpOnly
< status: 200 OK
< cache-control: private, max-age=0, must-revalidate
< x-runtime: 59
< etag: "ca627ebed10d753285a02237adbb93c2"
< set-cookie: blacklist_avatars=true; path=/
< set-cookie: blacklist_users=false; path=/
< set-cookie: e621=XXXX; path=/; expires=Sun, 18-Nov-2018 02:58:16 GMT; HttpOnly
< x-powered-by: Phusion Passenger 5.0.23
< x-frame-options: deny
< x-xss-protection: 1; mode=block
< x-content-type-options: nosniff
< expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< server: cloudflare
< cf-ray: 477d7f048fd0520f-MEL
< 
{ [74 bytes data]
100    74  100    74    0     0    134      0 --:--:-- --:--:-- --:--:--   134
* Connection #0 to host e621.net left intact

KiraNoot said:

For everyone trying to use javascript cross origin:
e621 doesn't really encourage embedding and creating third party interfaces for the site. They don't display ads, and they often don't take into regards the cost of the requests they make, how frequently they make them, and many other factors. So the CORS headers not being enabled isn't really a mistake, but to encourage third parties working in JS to stick to things that are read only, and to focus on areas that are lower impact.

Would it be possible to allow cors for certain sites if they agree to serve e621 ads? It would work like this:

developer creates website -> developer embeds e621 ads -> developer submits a review request -> e621 admin reviews the site and allows cors if they meet certain criteria (ads visible, not more than 2 requests per second, ...)

ethereal-wolf said:
Would it be possible to allow cors for certain sites if they agree to serve e621 ads? It would work like this:

developer creates website -> developer embeds e621 ads -> developer submits a review request -> e621 admin reviews the site and allows cors if they meet certain criteria (ads visible, not more than 2 requests per second, ...)

I can discuss it with the higher ups, but this might run into issues about where ads are displayed and campaign scope. Since we can't control the content of third party sites it complicates ad placement and obligations surrounding that. Yeah, I know, it always sounds weird, you'd think that an ad is an ad, regardless of where it's displayed, but it's also a trust agreement between the advertiser and the client(e621) about how and where it is displayed, so I can't simply authorize you to take our ads and display them on your site.

KiraNoot said:
I can discuss it with the higher ups, but this might run into issues about where ads are displayed and campaign scope. Since we can't control the content of third party sites it complicates ad placement and obligations surrounding that. Yeah, I know, it always sounds weird, you'd think that an ad is an ad, regardless of where it's displayed, but it's also a trust agreement between the advertiser and the client(e621) about how and where it is displayed, so I can't simply authorize you to take our ads and display them on your site.

Well, thank you for taking your time and reading this thread and helping, and I am pretty sure many people aside from me would be sincerely thankful if you could discuss the matter to the 'higher ups' as you call them.

I do understand though that something as ads is a slightly delicate topic for the trust, and control management, still, it isn't like everyone is going to have CORS access just because they requested it. I know that if that ever happpens, the measurements would be really strict to allow someone to have CORS access, but since it wouod be limited, I think that a discussion could be arranged between the requester and some admin/site manager or someone in charge of checking the other third party webs/apps to talk about where, how and when would the adds be displayed. Of course that is only a suggestion...

Personally, I started this topic because I would like to do a mobile/desktop application for the site. F-List has a mobile client, furaffinity has a mobile app too, so it would be pretty awesome to have one for this site. One that is specifically designed for mobile users or just people who want to have a desktop app... I don't care about the money or anything, and I would gladly put the respective ads wherever I am told to or stuff like that. Many people have many great ideas for different apps for the site that are awesome. And if at least some of those ideas are further developed through CORS, it would be such a great addition to all of the community and such a great advancement for the whole site....

Again, thanks for your time on reading all of this, best regards, Alastair~

Well, since this topic was started, I wanted to thank you all for the help you had given me. At the end the problem lies in the CORS restriction, but still I wanted to tank you all for helping me and taking your time to read and respond to this, so yeah, tank you all...
savageorange
KiraNoot
AoBird
ethereal-wolf