std::bad_castinvalid token supplied about jwt-cpp HOT 7 CLOSED

If I understand you correctly, you generate a token using jwt-cpp and then try to validate it using jwt-cpp and when validating, an exception is thrown.

Did you check if the token is correctly decoded by other verifiers, for example the one here:
https://jwt.io/

Can you post a sample token (can be expired) or at least a complete code sample showing the problem ?

The "invalid token supplied" message means that the token is not correctly formated (i.e. not in the header.payload.signature format).

from jwt-cpp.

Thanks for the quick response,

Here is the token create code:
auto token = jwt::create()
.set_issuer(JWT_ISSUER)
.set_type("JWT")
.set_payload_claim("name", std::string(uname))
.sign(jwt::algorithm::hs256{ passwd });

Here is the token verify code:
auto decoded_token = jwt::decode(token);
for (auto& e : decoded_token.get_payload_claims())
{
LOG_DBG << fname << e.first << " = " << e.second.as_string();
}
auto verifier = jwt::verify()
.allow_algorithm(jwt::algorithm::hs256{ key })
.with_issuer(JWT_ISSUER)
.with_claim("name", std::string(user));
verifier.verify(decoded_token);

above code works fine, but when I add set_expires_at(), it will failed.

Project:
https://github.com/laoshanxi/app-manager/blob/master/ApplicationManager/RestHandler.cpp

from jwt-cpp.

My bad I overlooked it the first time around:
Your problem is neither with token creation nor with verifying it.
It's your debug output of your token content.

You are trying to output the second element using as_string, which does not work in case of exp (which is a number).
If you just want to get a string representation of the content use to_json() instead, which also handles objects and the like correctly. For real checks you can either check the type using get_type() before printing or catch the exception.

I took a look at your project and noticed that you do quite a lot of stuff with the token content before calling verify. Even though it should be fine in this case, note that you can not trust ANY data in the token before it is validated and especially the fact that you print them out to a log file might help in case of attacks (you basically allow a remote user to write arbitrary data to your log file).

That said I really like the project. Looks like a mix between systemd and cron if I understood that correctly. I once tried something similar (webinterface to a systemd instance running in userspace) but eventually gave up on the idea and wrote a cli client of proxmox ve which builds and deploys tiny lxc contrainers. You can find it here: https://github.com/Thalhammer/pve-simple-container

from jwt-cpp.

Thanks to point out the root cause, it is my fault that did not debug into the application, after remove the debug log, it works.

You are right, the app-manager is target to be:

1. Manage all workload running on OS (more features than supervisor and crontab)
2. All self-built rpm post-install script will register an app to this daemon to manage startup behavior
3. Get resource usage for all applications
4. Run remote shell commands and get stdout/stderr (this is a little bit risk to open this)

Thanks again for the usefull library.

from jwt-cpp.

@Thalhammer Why I did some thing in gettoken is because I want follow standard to make token start with "Bearer ", is this correct?

from jwt-cpp.

Some use Bearer, some JWT.
Some use a completely different header.
There isn't really a standard on how to do this. In most of my software, I send JWT in the client and accept both Bearer and JWT on the server side.
But this is by no means a requirement.

from jwt-cpp.

@Thalhammer Thanks for the explaination. I saw most Java application follow "Bearer " starter. anyway, just make client/server consistant will be fine.

from jwt-cpp.