I'd like to add isExpired() to the SecurityToken API to support use-cases
where the expiration time is not known but the token is known to be expired.
To avoid boilerplate I've created an AbstractSecurityToken class that
implementations can extend. It has this method:
boolean isExpired() {
Long expiresAt = getExpiresAt();
return (expiresAt == null) ? false : System.currentTimeMillis() >
expiresAt;
}
Also, more questions
* getDomain() is only called once, it's used to add a default consumer key
for oauth requests. Since this is set by the ContainerConfig might it make
sense to not pass around this info in the token and instead grab it from the
config as needed? We already store the container name in the token.
* BlobCrypter classes use a fixed expiration time and stores the generated
time instead. Refactoring will be needed here...
On Fri, May 7, 2010 at 7:55 PM, John Hjelmstad <fa...@google.com> wrote:
> On Fri, May 7, 2010 at 5:59 PM, Paul Lindner <lind...@inuus.com> wrote:
>
> > I propose that we add expiration methods to the SecurityToken interface.
> > This is necessary for future OAuth2 compatibility. Here's the proposed
> > interface:
> >
> > /**
> > * @return the UTC timestamp (in milliseconds) that this token expires
> or
> > null if unknown or indeterminate
> > */
> > Long getExpiresAt();
> >
>
> +1
>
>
> >
> > /**
> > * @return true if the token is no longer valid
> > */
> > boolean isExpired();
> >
>
> +0 or maybe -0.1 -- is this really necessary? Seems like boilerplate.
>
> --j
>
