Empty `oauth_token` in the token request

[danse]

Hello, i am using this package with a server which expects token request parameters sent via POST, thus i am setting parameterMethod=RequestEntityBody. I had a failure while running requestTokenProtocol, i built a function to get the corresponding request, in order to inspect it, and i found that it has no body.

In the code there is mention about a possible reason. Since i am using parseThreeLegged the request has no body before being augmented. I don't understand how to fix the code, though. The problem should lie here but urlEncodedBody should add a body in any case, and fixQ ...

... uhm maybe the problem is fixQ. Maybe there is nothing there. I will keep digging into the code, but i have the feeling that something was silenced that had not to be. I had preferred getting an error rather than sending a POST with no body, getting the error back from the remote server and having to inspect what i am producing. I think that i am basically sending a malformed request

[danse]

I think that the empty body might be due to a Nothing returned by toQueryValue, not sure why it returns Nothing though. I tried providing a temporaryTokenRequest already containing a body, but it doesn't seem to help

[danse]

After trying with an initial body to eschew the problem described in the code, and after running a modified version of authenticated with fromJust substituting the mapMaybe building the body, i found out that the body was not empty, it was just not showing up. I found it hard to show the body but In the end i managed, and i found out that it contains &oauth_token=&. Does it make sense to send an empty oauth_token? I am not an expert about OAuth nor about Haskell, but i am willing to help if you want to assist me. We could add a minimal test suite in order to nail this

[danse]

As far as i can see, oauth_token is not expected in the first request. Maybe its presence is causing troubles with my server, which is particularly strict

[danse]

Weird that i find &oauth_token=&. fixQ seems to eliminate all parameters with a Nothing value

[ibotty]

Can you post a more complete snippet? It does not need to compile, just so that I can see what's going on.

Is the server publically accessible?

[danse]

Oh sure, i was working on a personal project to connect to Upwork's servers, to search for a job to do in Haskell :smile:.

This is the function that will fail against Upwork's servers, while you can use this from a stack repl in order to get the request and inspect it, and this to print it, obviously. You will need a key and secret, i will get in touch with you via mail about this to save you the time to get one.

I might be doing some dumb error in the way i am using this library, in that case i apologise in advance!

[danse]

Short update: oauth_token is sent without value because its value is not Nothing, but rather an empty string, due to this function which is compliant with the standard. I tried removing the line and sending the POST request without any oauth_token and the request is failing anyway. At this point it is well possible that the failure is not related to this library. I will keep troubleshooting and then close this issue.

Summarising, two factors made my troubleshooting slower:

• I needed time in order to build the request exactly as requestTokenProtocol' was building it
• I spent a lot of time figuring out how to show the request body

Probably, for a beginner user with a similar issue, a good advice is to use lower level functions. For the same reason, it could be helpful if the library exported more of its internal utility functions

[danse]

Actually at this point there is nothing wrong done by the library as far as i can tell, thus i can close this

[ibotty]

You are right, that debugging the library is not the easiest thing to do. I debugged running cabal repl within the project, but that's hardly comfortable or remotely user friendly. I will open a bug to discuss that further. BTW: You can try the other oauth library (authenticate-oauth). If that one works and oauthenticated doesn't, please reopen the bug! Even if oauthenticated is right, we don't want to be pedantic ;).

[danse]

Well this is not far from being user friendly, i just had to write this function to build the first request. I copied the code from this function within Oauthenticated, so maybe you could abstract part of it in order to make it easier to get the request, and that would help a little bit. Not a big deal though.

The other problem i had was with visualising the POST body. That is a problem with http-client, mentioned in this issue, unrelated from Oauthenticated.

What strikes me more, now, is the existence of authenticate-oauth, the other library you are referring to. I spent a bit looking for the right Oauth client library, but somehow i missed that one, which seems to have way more forks that this one, so it had been a preferable choice for me at first, since i am a beginner. Discoverability of Haskell libraries is a bit of a challenge sometimes, so it would help a lot if you referred that library here, for example in the README after you mention that this is still in alpha

[danse]

I just wanted to mention that i had the chance to use authenticate-oauth towards that server and it worked, so the problem does not seem to be in the server implementation

[ibotty]

Re: authenticate-oauth: without speaking for tel, I found it's API to be less type safe. That was the reason I switched to oauthenticated.

Unfortunately oauth is a complicated beast, so there can easily be inconsistencies between client and server implementations. authenticate-oauth surely is more battle-tested. I personally switched to using oauth 2 (and oidc) for my authX needs, so I won't work much on oauthenticated.

If you want to debug further (start fixing things within oauthenticated wasn't hard when I started), look at the headers you set and compare the code path's for the two oauth libs (or read the spec, but I don't think the problem lies in that part). It might well be that you set different Accept headers or something similar.

[danse]

Hey, thanks for following up, but i think that we can close this. I don't think that i will spend more time in a comparison or debugging effort