Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove signWith method from JwtBuilder Interface that takes String param #146

Closed
dogeared opened this issue Jul 13, 2016 · 6 comments
Closed
Milestone

Comments

@dogeared
Copy link
Contributor

In JwtBuilder, there's a variant of the signWith method:

JwtBuilder signWith(SignatureAlgorithm alg, String base64EncodedSecretKey);

Although the method signature is clear, people may misunderstand its intent.

Removing this signature will force people to always sign with a byte[] or with a java.security.Key, thereby insuring that best practices are adhered to.

If we want to provide a way for developers for pass in a base64 encoded byte array, we could provide a static method elsewhere that takes a String, base64 decodes it, and returns a byte array.

Note: implementing this issue may address #143

@dogeared dogeared changed the title Remove String signWith method from JwtBuilder Interface Remove signWith method from JwtBuilder Interface that takes String param Jul 13, 2016
@lhazlewood
Copy link
Contributor

no need for a static method - they can use TextCodec.BASE64.decode(aString); :)

@EralpB
Copy link

EralpB commented May 21, 2017

This also got me puzzled.. I think you should remove the String version, I was just checking a string signature like "a" and created one JWT online in a custom manner, of course they didn't match and it was confusing a bit.

@lhazlewood
Copy link
Contributor

Assigned to milestone 1.0 because this is a backwards-incompatible change that semver requires updating the major revision number

@lhazlewood
Copy link
Contributor

lhazlewood commented Sep 9, 2023

Note: this should be done as part of #339

@pveeckhout
Copy link

pveeckhout commented Dec 25, 2023

can this ticket / issue be closed?

the method in question has been annotated with @Deprecated and will be removed in #339 as described above by @lhazlewood

@lhazlewood
Copy link
Contributor

@pveeckhout you're right, this can be closed in favor of just using #339 to track the work. Thanks for the comment!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants