GithubHelp home page GithubHelp logo

auth-tokens's People

Contributors

a-k-g avatar ags799 avatar bavardage avatar bulldozer-bot[bot] avatar carterkozak avatar dansanduleac avatar diogoholanda avatar ellisjoe avatar gatesn avatar hturki avatar iamdanfox avatar j-baker avatar jkozlowski avatar markelliot avatar mglazer avatar mnazbro avatar nmiyake avatar pkoenig10 avatar pnepywoda avatar qinfchen avatar robert3005 avatar sandorw avatar shashiadi avatar snegrus-adb avatar svc-autorelease avatar svc-excavator-bot avatar uschi2000 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

auth-tokens's Issues

Please add AuthHeader serializability note to 0.2.4 release notes

At https://github.com/palantir/auth-tokens/releases/tag/0.2.4

Proposed language:

  • Note that AuthHeader is no longer JSON-serializable as it should be used for @HeaderParams only. Use BearerToken instead which is and should be serializable.

This is technically a backcompat breaking change (I had to change a downstream project to accommodate) so we should at least make note of it in release notes even though we're still in 0.x versions.

cc @pnepywoda

Excessive stack traces when token is not a JWT

Every time my Dropwizard app gets a request with a non JWT bearer token (e.g. Authorization: Bearer <shared-secret>), the auth-tokens-filter spits out the following stacktrace. This lowers the signal-to-noise ratio in my logs and makes them much harder to read. What do you think about dialing this down to a debug log line?

DEBUG [2017-05-27 01:33:11,787] com.palantir.tokens.auth.http.BearerTokenLoggingFilter: Unable to process auth header.
! java.lang.IllegalArgumentException: BearerToken must match pattern ^[A-Za-z0-9\-\._~\+/]+=*$
! at com.palantir.tokens.auth.BearerToken.valueOf(BearerToken.java:49)
! at com.palantir.tokens.auth.AuthHeader.valueOf(AuthHeader.java:37)
! at com.palantir.tokens.auth.http.BearerTokenLoggingFilter.filter(BearerTokenLoggingFilter.java:51)
! at org.glassfish.jersey.server.ContainerFilteringStage.apply(ContainerFilteringStage.java:132)
! at org.glassfish.jersey.server.ContainerFilteringStage.apply(ContainerFilteringStage.java:68)
! at org.glassfish.jersey.process.internal.Stages.process(Stages.java:197)
! at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:318)
! at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
! at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
! at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
! at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
! at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
! at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
! at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305)
! at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154)
! at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:473)
! at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:427)
! at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:388)
! at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:341)
! at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:228)
! at io.dropwizard.jetty.NonblockingServletHolder.handle(NonblockingServletHolder.java:49)
! at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1689)
! at io.dropwizard.servlets.ThreadNameFilter.doFilter(ThreadNameFilter.java:34)
! at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676)
! at io.dropwizard.jersey.filter.AllowedMethodsFilter.handle(AllowedMethodsFilter.java:50)
! at io.dropwizard.jersey.filter.AllowedMethodsFilter.doFilter(AllowedMethodsFilter.java:44)
! at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676)
! at com.palantir.websecurity.filters.JerseyAwareWebSecurityFilter.doFilter(JerseyAwareWebSecurityFilter.java:63)
! at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676)
! at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
! at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1174)
! at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
! at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1106)
! at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
! at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
! at com.codahale.metrics.jetty9.InstrumentedHandler.handle(InstrumentedHandler.java:240)
! at io.dropwizard.jetty.RoutingHandler.handle(RoutingHandler.java:51)
! at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:459)
! at io.dropwizard.jetty.BiDiGzipHandler.handle(BiDiGzipHandler.java:68)
! at org.eclipse.jetty.server.handler.RequestLogHandler.handle(RequestLogHandler.java:56)
! at org.eclipse.jetty.server.handler.StatisticsHandler.handle(StatisticsHandler.java:169)
! at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
! at org.eclipse.jetty.server.Server.handle(Server.java:524)
! at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:319)
! at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:253)
! at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
! at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
! at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:186)
! at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
! at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
! at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
! at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
! at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
! at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
! at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
! at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
! at java.lang.Thread.run(Thread.java:748)

Other types of tokens?

Is there any plans to include functionality for other types of tokens (besides Bearer)? There are some APIs out there that use other token types (ie. Basic tokens and base64 encode the clientId:clientSecret tuple, etc.). I am fully aware that things that use mechanisms like Basic Authorization aren't secure, but nonetheless there are APIs out there that still use them :(

I'd be happy to contribute an implementation for something like a Basic token, potentially allowing some union type encapsulated within the AuthHeader type?

Provide method for getting user id from header

Hey all,
We've found it useful to have code that extracts the 'sub' field from a JWT auth header.
Obviously we can't trust this, but it's useful for logging - being able to say that a certain user made a given request is useful without having to pull in all the complexity of an auth bundle.

Would a getUserIdInsecure() method be welcome as part of the AuthHeader or the BearerToken class?

Immutable Style classes not found

The auth-tokens module uses @Immutables but does not include the annotations as compile time dependencies (it cannot find the styles classes). This causes downstream java warnings.

Two possible solutions would be to:

  1. include the annotations in the classpath:

    compile group: 'org.immutables', name: 'value', classifier: 'annotations'
    
  2. create and switch to an annotation provided in the auth-tokens module itself (i.e. something named @ImmutableStyles)

would a PR that does 2 make sense?

ClassCastException calling UnverifiedJsonWebToken of(BearerToken token)

using auth-tokens 1.0.1

Executing the following very simple code

UnverifiedJsonWebToken jwt = UnverifiedJsonWebToken.of(BearerToken.valueOf(BEARER_TOKEN));
System.out.println(jwt.getUnverifiedUserId());
System.out.println(jwt.getUnverifiedSessionId());

Where BEARER_TOKEN is a valid bearer token, I hit this:

java.lang.ClassCastException: java.lang.String cannot be cast to [B
    at com.palantir.tokens.auth.UnverifiedJsonWebToken$1.apply(UnverifiedJsonWebToken.java:48)
    at com.google.common.base.Present.transform(Present.java:71)
    at com.palantir.tokens.auth.UnverifiedJsonWebToken.of(UnverifiedJsonWebToken.java:85)

I can see in the debugger that the JsonWebTokenPayload.sid field that should be an Optional<byte[]> has actually been deserialised to an Optional<String>, hence the cast exception when something tries to use it.

The decoded segment of the token that the ObjectMapper fails to deserialize properly looks like this:

{"exp":1490934829,"sid":"DaZqW62fQUe3coo2CL+B7Q==","sub":"595020GOSXOXlxzQBgKJlQ=="}

Add helper that registers the BearerTokenLoggingContextFilter

Many clients register the BearerTokenLoggingContextFilter with a default configuration that looks something like this:

env.servlets()
        .addFilter("BearerTokenLoggingContext", BearerTokenLoggingContextFilter.class)
        .addMappingForUrlPatterns(EnumSet.allOf(DispatcherType.class), true, "/*");

Some options to make this more convenient are:

  1. Add void install(ServletEnvironment) to BearerTokenLoggingContextFilter
  2. convert BearerTokenLoggingContextFilter from a ServletFilter to a JerseyFilter (make it implement both?), where the latter would show up as env.jersey().register(BearerTokenLoggingContextFilter.class)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.