Claim Does Not Include Data about jwt-scala HOT 11 CLOSED

This code looks pretty good. Let's check when you send the token after login. Play should send a response with an Authorization header containing the token. It is composed of 3 parts separated by dots: header.claim.signature. Could you take just the claim and use a site like this one to decode its content? Does it contains a user key inside the JSON? If not, the problem is when creating the token.

from jwt-scala.

The decoded claim is:
{"exp":1444878528,"user":"10"}

from jwt-scala.

Ok. Could you add:

println(JwtSession.HEADER_NAME)
println(JwtSession.TOKEN_PREFIX)
println(request.headers.get(JwtSession.HEADER_NAME))
println(request.jwtSession.claimData)

just before the first pattern matching? (you might need to import pdi.jwt.JwtSession) And copy/paste the result here?

from jwt-scala.

Also, there is a problem: you are asking for an Int (getAs[Int]) but you put a String in it (user.id.toString), that cannot match. You need to fix that.

from jwt-scala.

Thanks for the response!

Here is the output you requested:
Authorization
Bearer
Some(Bearer yJ0eXAiOiJKV1QiLCJhbGciOiJIbWFjU0hBMjU2In0.eyJleHAiOjE0NDQ5MzIyMzcsInVzZXIiOiIxMCJ9.z_iAclFqEBljMgP7S3w-lhbm1AceKCEdc2SrALlQ4M8)
{"exp":1444932313}

And good catch on the getAs[Int] part, but that unfortunately didn't solve the issue (as evident by the missing data in the claimData output).

from jwt-scala.

Ok, it's getting tricky here. My best guess is that something went wrong when decoding the token so it created a new JwtSession as a fallback. The fact that the expiration is not the same between the request header (1444932237) and the request.jwtSession.claimData (1444932313) points in this direction too.

Not sure it's a good idea to have a new empty session if it fails to decode the token, but that's what Play is doing for its cookie session.... maybe I should add a new API...

Anyway, it's really hard for me to help you more with just that... Do you think you could setup a small project in GitHub to reproduce the problem? Otherwise, you want to debug why this line is failing do decode the token.

from jwt-scala.

Hi Paul, I appreciate you sticking with me here.

Unfortunately, I don't think a sample GitHub repo would really help since I don't use a typical Json Reads/Writes/Formats for my users object; it would be pretty difficult to debug.

I'll do my best to keep digging and respond with what I find. So far, through the debugging process, I've found:
Upon entering JwtSession.deserialize(...), the the method you linked previously, it appears to read the crypto key correctly and enters Jwt.decodeRawAll at Jwt Line 242. decodeRawAll splits the token, and out comes a tuple containing the claim. The claim, at this point, contains the Json Object: {"exp":1444932237,"user":"10"} (as expected). So it appears that the claim is being correctly decoded. Once it reaches the next step Jwt Line 243, which is the validation step, it seems to fail.

I did notice that it attempts to parse the header, and when debugging that part, the header seems to contain a bunch of nonsense: ȝ�\����������[�Ȏ���XX���L�M�� . I have a feeling there's an issue here. It's hard to tell, but I think it's just throwing an exception which is never caught, so it's hard to see exactly what's going on. I'm going to keep digging to see what I can find from here. I'll get back to you.

from jwt-scala.

One thing I noticed through debugging is that when the token header is created, it does not contain a content type. I'm not sure if that's required, but my gut instinct tells me that the cty should be set to application/json. Without that piece of information, how does the validation step know how to understand the contents of the header/claim?

Perhaps I missed a configuration step?

from jwt-scala.

Good catch for the header! That's probably the problem. The one from the token you copy/pasted before decode base64 with the stranged value you saw. You can see that inside a browser console:

atob('yJ0eXAiOiJKV1QiLCJhbGciOiJIbWFjU0hBMjU2In0')
È��\�����Õ����[�È����XXÔÒ�L�M��"

First, you need to check if your server is sending a valid header or not inside the header response during login. Next, you need to check if you're not doing anything wrong when storing it client side.

The cty parameter is totally optional and it's recommended not to use it actually. Its value has no link with the one for a HTTP response, a JWT token is always JSON. The cty parameter is for the type of token you are using, but it will always be the default value JWT in your case.

from jwt-scala.

Well, after debugging this for days and digging through tons and tons of lines of your library's code, I've come to the conclusion that I am an idiot. I did as you suggested and looked at the token that was sent to the client upon a successful login and compared it to the one that was being stored/sent with future requests to the server; they didn't match. The token was off by one character, and that's when I realized that in my JS, I was taking a substring of the authorization header authHeader.substring(8), when it was supposed to be authHeader.substring(7). All the while, I was thinking there must be something wrong with the backend since the claim was correct, but the header was not. Only the header section of the token was affected, so that explains the gibberish that came from the decoding.

Long story short, this one was my fault, so I apologize for sending you on a wild goose chase.

from jwt-scala.

No worries, glad you fixed it.

from jwt-scala.