You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by "Cassie Doll (JIRA)" <ji...@apache.org> on 2008/10/01 01:39:44 UTC
[jira] Created: (SHINDIG-635) Add a new method to SecurityToken -
getContainer()
Add a new method to SecurityToken - getContainer()
--------------------------------------------------
Key: SHINDIG-635
URL: https://issues.apache.org/jira/browse/SHINDIG-635
Project: Shindig
Issue Type: New Feature
Components: Common Components (Java)
Reporter: Cassie Doll
I'd like to add a new method to the SecurityToken interface called getContainer(). This will return the current container that is being rendered. With the container and the ContainerConfig any consumers of the SecurityToken interface can look up any parameter that they may need.
Does anybody think this will be a problem?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (SHINDIG-635) Add a new method to SecurityToken - getContainer()
Posted by Cassie <do...@google.com>.
Because this method is the only method that allows clean container specific
extensibility.
If we do not add this method we could instead add:
// Returns the parameter mapped with the specific key
public String getParameter(String key);
That would be fine as well. Without these methods social consumers of the
SecurityToken class would need to constantly cast down to their own token
base class if they want token extensions. That's pretty messy when we could
just add one method to handle extensibility.
The current shindig sample container is only responding to queries from one
container. If we had it respond to queries from multiple containers then it
would demonstrate a need for this functionality in one form or another. (If
that sounds good its work for another patch though)
- Cassie
On Wed, Oct 1, 2008 at 11:13 AM, Brian Eaton <be...@google.com> wrote:
> On Wed, Oct 1, 2008 at 9:41 AM, Cassie <do...@google.com> wrote:
> > My specific ask for this bug is much much simpler. Most of the token
> > implementations that we have already know what the container is. I am
> just
> > proposing adding a getter for the field and pulling it up into the
> > SecurityToken interface. I'm also not proposing that we need to use this
> > anywhere in the shindig code.
>
> Philosophical objection: why should we clutter the Shindig code with
> interfaces that Shindig doesn't use?
>
Re: [jira] Created: (SHINDIG-635) Add a new method to SecurityToken - getContainer()
Posted by Ropu <ro...@gmail.com>.
i'll go for the .getContainer().
Once happened to me in an integration that i needed on extra field in the
ST, and getExtraField() was the *logic* solution for my custom extension.
ropu
On Thu, Oct 2, 2008 at 6:50 PM, Brian Eaton <be...@google.com> wrote:
> On Thu, Oct 2, 2008 at 2:41 PM, Cassie <do...@google.com> wrote:
> > Anybody else want to chime in?
> > We can either:
> >
> > 1. add SecurityToken.getContainer
> > 2. add SecurityToken.getParameter(String key)
> > 3. leave it as is and go find a different solution for SecurityToken
> > extensions
>
> My rough order of preference:
> - find a different solution, though I've got no idea what one would look
> like.
> - SecurityToken.getContainer()
> - getParameter(String key)
>
> I don't like getParameter(String key) because it forces us to treat
> all security token extensions as Strings. What if it's a List? What
> if it's something else entirely?
>
> Hrm. I do have some idea of what a good solution would look like, but
> so far everytime I mention it people give me dirty looks. I'll try it
> out on shindig-dev just to see where things go:
>
> Assuming that all instances of SecurityToken are generated by
> deployment specific code, Shindig deployers can implement a single
> subclass of SecurityToken for all SecurityToken instances they
> generate. Shindig SPI implementations can then cast down to that
> SecurityToken subclass. This type of pattern is remarkably common in
> old school C code: opaque void* pointers are tossed around anywhere
> you have two APIs that can't have compile time dependencies but do
> need to call each other at runtime.
>
--
.-. --- .--. ..-
R o p u
Re: [jira] Created: (SHINDIG-635) Add a new method to SecurityToken - getContainer()
Posted by Louis Ryan <lr...@google.com>.
I have the feeling that the need to carry arbitrary properties around is
inevitable so +1 for st.getContainer which delegates to
st.getParameter(key) where key is a reserved constant.
Hopefully people will realize that they can't stuff this like a Xmas
stocking
On Thu, Oct 2, 2008 at 10:56 PM, Brian Eaton <be...@google.com> wrote:
> On Thu, Oct 2, 2008 at 9:34 PM, Evan Gilbert <ui...@google.com> wrote:
> > Request scoped Guice variables handle this much more
> > cleanly.
>
> Do you have some example code for this? Would it work something like this:
>
> - SecurityTokenDecoder verifies token, sticks verified token in ether
> fully typed
> - Code running later on in request processing magically pulls token
> (as full type) out of ether
>
> Setting credentials as thread-local is sometimes used for this kind of
> thing, but I can't see that working for something that uses thread
> pools as much as Shindig.
>
Re: [jira] Created: (SHINDIG-635) Add a new method to SecurityToken -
getContainer()
Posted by Evan Gilbert <ui...@google.com>.
Brian - you can create request scoped variables by calling:
bind(Foo.class).to(Bar.class).in(RequestScoped.class);
Request scoping may also automatic if your constructor takes a RequestScoped
object. For example, AuthInfo takes an HttpServletRequest as a constuctor
arg, so by default it is scoped to the request.
Kevin - we can create our own request scope type that matches our logical
request scope. Separate thread for processing doesn't prevent request-scoped
injection, just means that you have to do more work.
The alternative of passing all parameters that any class needs anywhere down
the call chain on the SecurityToken seems to be an unscalable design.
Evan
On Fri, Oct 3, 2008 at 1:50 PM, Kevin Brown <et...@google.com> wrote:
> On Thu, Oct 2, 2008 at 10:56 PM, Brian Eaton <be...@google.com> wrote:
>
> > On Thu, Oct 2, 2008 at 9:34 PM, Evan Gilbert <ui...@google.com> wrote:
> > > Request scoped Guice variables handle this much more
> > > cleanly.
> >
> > Do you have some example code for this? Would it work something like
> this:
> >
> > - SecurityTokenDecoder verifies token, sticks verified token in ether
> > fully typed
> > - Code running later on in request processing magically pulls token
> > (as full type) out of ether
> >
> > Setting credentials as thread-local is sometimes used for this kind of
> > thing, but I can't see that working for something that uses thread
> > pools as much as Shindig.
>
>
> And, in fact, it doesn't work because HTTP request processing is frequently
> done on a separate thread from the one processing the request.
>
Re: [jira] Created: (SHINDIG-635) Add a new method to SecurityToken - getContainer()
Posted by Kevin Brown <et...@google.com>.
On Thu, Oct 2, 2008 at 10:56 PM, Brian Eaton <be...@google.com> wrote:
> On Thu, Oct 2, 2008 at 9:34 PM, Evan Gilbert <ui...@google.com> wrote:
> > Request scoped Guice variables handle this much more
> > cleanly.
>
> Do you have some example code for this? Would it work something like this:
>
> - SecurityTokenDecoder verifies token, sticks verified token in ether
> fully typed
> - Code running later on in request processing magically pulls token
> (as full type) out of ether
>
> Setting credentials as thread-local is sometimes used for this kind of
> thing, but I can't see that working for something that uses thread
> pools as much as Shindig.
And, in fact, it doesn't work because HTTP request processing is frequently
done on a separate thread from the one processing the request.
Re: [jira] Created: (SHINDIG-635) Add a new method to SecurityToken - getContainer()
Posted by Brian Eaton <be...@google.com>.
On Thu, Oct 2, 2008 at 9:34 PM, Evan Gilbert <ui...@google.com> wrote:
> Request scoped Guice variables handle this much more
> cleanly.
Do you have some example code for this? Would it work something like this:
- SecurityTokenDecoder verifies token, sticks verified token in ether
fully typed
- Code running later on in request processing magically pulls token
(as full type) out of ether
Setting credentials as thread-local is sometimes used for this kind of
thing, but I can't see that working for something that uses thread
pools as much as Shindig.
Re: [jira] Created: (SHINDIG-635) Add a new method to SecurityToken -
getContainer()
Posted by Evan Gilbert <ui...@google.com>.
+1 for SecurityToken.getContainer(). This seems to be a reasonable and
standard extension - you need to know context about the page upon which your
gadget had rendered.
---1 on getParameter(). This is using SecurityToken as an arbitrary context
to pass data around. Request scoped Guice variables handle this much more
cleanly.
On Thu, Oct 2, 2008 at 5:26 PM, Kevin Brown <et...@google.com> wrote:
> On Thu, Oct 2, 2008 at 2:50 PM, Brian Eaton <be...@google.com> wrote:
>
> > On Thu, Oct 2, 2008 at 2:41 PM, Cassie <do...@google.com> wrote:
> > > Anybody else want to chime in?
> > > We can either:
> > >
> > > 1. add SecurityToken.getContainer
> > > 2. add SecurityToken.getParameter(String key)
> > > 3. leave it as is and go find a different solution for SecurityToken
> > > extensions
> >
> > My rough order of preference:
> > - find a different solution, though I've got no idea what one would look
> > like.
> > - SecurityToken.getContainer()
> > - getParameter(String key)
> >
> > I don't like getParameter(String key) because it forces us to treat
> > all security token extensions as Strings. What if it's a List? What
> > if it's something else entirely?
>
>
> Realistically, it's going to be a string or something that easily
> serializes
> as a string. The security token is only so big.
>
>
> > Hrm. I do have some idea of what a good solution would look like, but
> > so far everytime I mention it people give me dirty looks. I'll try it
> > out on shindig-dev just to see where things go:
> >
> > Assuming that all instances of SecurityToken are generated by
> > deployment specific code, Shindig deployers can implement a single
> > subclass of SecurityToken for all SecurityToken instances they
> > generate. Shindig SPI implementations can then cast down to that
> > SecurityToken subclass. This type of pattern is remarkably common in
> > old school C code: opaque void* pointers are tossed around anywhere
> > you have two APIs that can't have compile time dependencies but do
> > need to call each other at runtime.
>
>
> Yeah, but down casting is problematic. C libraries generally don't mix and
> match with each other -- the pointer is opaque to everything but the code
> that produced it. They use opaque pointers so that consumers of the library
> don't do dumb things with them.
>
> In this case, both the code using the object and the code that produced it
> need to work with it.
>
Re: [jira] Created: (SHINDIG-635) Add a new method to SecurityToken - getContainer()
Posted by Kevin Brown <et...@google.com>.
On Thu, Oct 2, 2008 at 2:50 PM, Brian Eaton <be...@google.com> wrote:
> On Thu, Oct 2, 2008 at 2:41 PM, Cassie <do...@google.com> wrote:
> > Anybody else want to chime in?
> > We can either:
> >
> > 1. add SecurityToken.getContainer
> > 2. add SecurityToken.getParameter(String key)
> > 3. leave it as is and go find a different solution for SecurityToken
> > extensions
>
> My rough order of preference:
> - find a different solution, though I've got no idea what one would look
> like.
> - SecurityToken.getContainer()
> - getParameter(String key)
>
> I don't like getParameter(String key) because it forces us to treat
> all security token extensions as Strings. What if it's a List? What
> if it's something else entirely?
Realistically, it's going to be a string or something that easily serializes
as a string. The security token is only so big.
> Hrm. I do have some idea of what a good solution would look like, but
> so far everytime I mention it people give me dirty looks. I'll try it
> out on shindig-dev just to see where things go:
>
> Assuming that all instances of SecurityToken are generated by
> deployment specific code, Shindig deployers can implement a single
> subclass of SecurityToken for all SecurityToken instances they
> generate. Shindig SPI implementations can then cast down to that
> SecurityToken subclass. This type of pattern is remarkably common in
> old school C code: opaque void* pointers are tossed around anywhere
> you have two APIs that can't have compile time dependencies but do
> need to call each other at runtime.
Yeah, but down casting is problematic. C libraries generally don't mix and
match with each other -- the pointer is opaque to everything but the code
that produced it. They use opaque pointers so that consumers of the library
don't do dumb things with them.
In this case, both the code using the object and the code that produced it
need to work with it.
Re: [jira] Created: (SHINDIG-635) Add a new method to SecurityToken - getContainer()
Posted by Brian Eaton <be...@google.com>.
On Thu, Oct 2, 2008 at 2:41 PM, Cassie <do...@google.com> wrote:
> Anybody else want to chime in?
> We can either:
>
> 1. add SecurityToken.getContainer
> 2. add SecurityToken.getParameter(String key)
> 3. leave it as is and go find a different solution for SecurityToken
> extensions
My rough order of preference:
- find a different solution, though I've got no idea what one would look like.
- SecurityToken.getContainer()
- getParameter(String key)
I don't like getParameter(String key) because it forces us to treat
all security token extensions as Strings. What if it's a List? What
if it's something else entirely?
Hrm. I do have some idea of what a good solution would look like, but
so far everytime I mention it people give me dirty looks. I'll try it
out on shindig-dev just to see where things go:
Assuming that all instances of SecurityToken are generated by
deployment specific code, Shindig deployers can implement a single
subclass of SecurityToken for all SecurityToken instances they
generate. Shindig SPI implementations can then cast down to that
SecurityToken subclass. This type of pattern is remarkably common in
old school C code: opaque void* pointers are tossed around anywhere
you have two APIs that can't have compile time dependencies but do
need to call each other at runtime.
Re: [jira] Created: (SHINDIG-635) Add a new method to SecurityToken - getContainer()
Posted by Cassie <do...@google.com>.
Anybody else want to chime in?
We can either:
1. add SecurityToken.getContainer
2. add SecurityToken.getParameter(String key)
3. leave it as is and go find a different solution for SecurityToken
extensions
- Cassie
On Wed, Oct 1, 2008 at 11:51 AM, Kevin Brown <et...@google.com> wrote:
> On Wed, Oct 1, 2008 at 11:13 AM, Brian Eaton <be...@google.com> wrote:
>
> > On Wed, Oct 1, 2008 at 9:41 AM, Cassie <do...@google.com> wrote:
> > > My specific ask for this bug is much much simpler. Most of the token
> > > implementations that we have already know what the container is. I am
> > just
> > > proposing adding a getter for the field and pulling it up into the
> > > SecurityToken interface. I'm also not proposing that we need to use
> this
> > > anywhere in the shindig code.
> >
> > Philosophical objection: why should we clutter the Shindig code with
> > interfaces that Shindig doesn't use?
>
>
> We *would* use it if it existed. Right now we have to pass container
> separately for many operations where the security token is already passed.
> This would eliminate that requirement.
>
> I actually agree with Cassie's next point more though. getParameter seems
> like a much cleaner extensibility mechanism.
>
Re: [jira] Created: (SHINDIG-635) Add a new method to SecurityToken - getContainer()
Posted by Kevin Brown <et...@google.com>.
On Wed, Oct 1, 2008 at 11:13 AM, Brian Eaton <be...@google.com> wrote:
> On Wed, Oct 1, 2008 at 9:41 AM, Cassie <do...@google.com> wrote:
> > My specific ask for this bug is much much simpler. Most of the token
> > implementations that we have already know what the container is. I am
> just
> > proposing adding a getter for the field and pulling it up into the
> > SecurityToken interface. I'm also not proposing that we need to use this
> > anywhere in the shindig code.
>
> Philosophical objection: why should we clutter the Shindig code with
> interfaces that Shindig doesn't use?
We *would* use it if it existed. Right now we have to pass container
separately for many operations where the security token is already passed.
This would eliminate that requirement.
I actually agree with Cassie's next point more though. getParameter seems
like a much cleaner extensibility mechanism.
Re: [jira] Created: (SHINDIG-635) Add a new method to SecurityToken - getContainer()
Posted by Brian Eaton <be...@google.com>.
On Wed, Oct 1, 2008 at 9:41 AM, Cassie <do...@google.com> wrote:
> My specific ask for this bug is much much simpler. Most of the token
> implementations that we have already know what the container is. I am just
> proposing adding a getter for the field and pulling it up into the
> SecurityToken interface. I'm also not proposing that we need to use this
> anywhere in the shindig code.
Philosophical objection: why should we clutter the Shindig code with
interfaces that Shindig doesn't use?
Re: [jira] Created: (SHINDIG-635) Add a new method to SecurityToken - getContainer()
Posted by Cassie <do...@google.com>.
My specific ask for this bug is much much simpler. Most of the token
implementations that we have already know what the container is. I am just
proposing adding a getter for the field and pulling it up into the
SecurityToken interface. I'm also not proposing that we need to use this
anywhere in the shindig code.
The specific implementation that I am working on needs extra information
from the ContainerConfig.. which is keyed off of the container... which is
currently stuck behind the interface. Allowing consumers of the token to get
the current container makes adding new container-specific params to the json
backing the ContainerConfig very easy.
I'm attaching a patch now to clear up what I meant. Please let me know what
you think.
Thanks!
- Cassie
On Wed, Oct 1, 2008 at 9:33 AM, Kevin Brown <et...@google.com> wrote:
> On Wed, Oct 1, 2008 at 8:53 AM, Chris Chabot <ch...@google.com> wrote:
>
> > that would be very welcome ... well that and including the security token
> > in
> > proxy posts (added security + being able to load container specific
> config
> > for proxy requests too, like, what http fetcher class to use)
>
>
> Are you referring to makeRequest or the open proxy? I'd be hesitant to
> include the security token in open proxy requests due to caching
> implications, but it should be passed in makeRequest already.
>
>
> >
> >
> > On Wed, Oct 1, 2008 at 4:16 PM, Ropu <ro...@gmail.com> wrote:
> >
> > > Hi Cassie, im working on the update of the way we user the ST in PHP.
> > >
> > > Can you elaborate a little more on how will affect the code that uses
> de
> > > ST?
> > >
> > > And obviously we need to update the way we generate it in the iframe
> url.
> > >
> > > anything else?
> > >
> > > thanks
> > >
> > > ropu
> > >
> > > On Tue, Sep 30, 2008 at 8:39 PM, Cassie Doll (JIRA) <ji...@apache.org>
> > > wrote:
> > >
> > > > Add a new method to SecurityToken - getContainer()
> > > > --------------------------------------------------
> > > >
> > > > Key: SHINDIG-635
> > > > URL:
> https://issues.apache.org/jira/browse/SHINDIG-635
> > > > Project: Shindig
> > > > Issue Type: New Feature
> > > > Components: Common Components (Java)
> > > > Reporter: Cassie Doll
> > > >
> > > >
> > > > I'd like to add a new method to the SecurityToken interface called
> > > > getContainer(). This will return the current container that is being
> > > > rendered. With the container and the ContainerConfig any consumers of
> > the
> > > > SecurityToken interface can look up any parameter that they may need.
> > > >
> > > > Does anybody think this will be a problem?
> > > >
> > > > --
> > > > This message is automatically generated by JIRA.
> > > > -
> > > > You can reply to this email to add a comment to the issue online.
> > > >
> > > >
> > >
> > >
> > > --
> > > .-. --- .--. ..-
> > > R o p u
> > >
> >
>
Re: [jira] Created: (SHINDIG-635) Add a new method to SecurityToken - getContainer()
Posted by Kevin Brown <et...@google.com>.
On Wed, Oct 1, 2008 at 8:53 AM, Chris Chabot <ch...@google.com> wrote:
> that would be very welcome ... well that and including the security token
> in
> proxy posts (added security + being able to load container specific config
> for proxy requests too, like, what http fetcher class to use)
Are you referring to makeRequest or the open proxy? I'd be hesitant to
include the security token in open proxy requests due to caching
implications, but it should be passed in makeRequest already.
>
>
> On Wed, Oct 1, 2008 at 4:16 PM, Ropu <ro...@gmail.com> wrote:
>
> > Hi Cassie, im working on the update of the way we user the ST in PHP.
> >
> > Can you elaborate a little more on how will affect the code that uses de
> > ST?
> >
> > And obviously we need to update the way we generate it in the iframe url.
> >
> > anything else?
> >
> > thanks
> >
> > ropu
> >
> > On Tue, Sep 30, 2008 at 8:39 PM, Cassie Doll (JIRA) <ji...@apache.org>
> > wrote:
> >
> > > Add a new method to SecurityToken - getContainer()
> > > --------------------------------------------------
> > >
> > > Key: SHINDIG-635
> > > URL: https://issues.apache.org/jira/browse/SHINDIG-635
> > > Project: Shindig
> > > Issue Type: New Feature
> > > Components: Common Components (Java)
> > > Reporter: Cassie Doll
> > >
> > >
> > > I'd like to add a new method to the SecurityToken interface called
> > > getContainer(). This will return the current container that is being
> > > rendered. With the container and the ContainerConfig any consumers of
> the
> > > SecurityToken interface can look up any parameter that they may need.
> > >
> > > Does anybody think this will be a problem?
> > >
> > > --
> > > This message is automatically generated by JIRA.
> > > -
> > > You can reply to this email to add a comment to the issue online.
> > >
> > >
> >
> >
> > --
> > .-. --- .--. ..-
> > R o p u
> >
>
Re: [jira] Created: (SHINDIG-635) Add a new method to SecurityToken - getContainer()
Posted by Chris Chabot <ch...@google.com>.
that would be very welcome ... well that and including the security token in
proxy posts (added security + being able to load container specific config
for proxy requests too, like, what http fetcher class to use)
On Wed, Oct 1, 2008 at 4:16 PM, Ropu <ro...@gmail.com> wrote:
> Hi Cassie, im working on the update of the way we user the ST in PHP.
>
> Can you elaborate a little more on how will affect the code that uses de
> ST?
>
> And obviously we need to update the way we generate it in the iframe url.
>
> anything else?
>
> thanks
>
> ropu
>
> On Tue, Sep 30, 2008 at 8:39 PM, Cassie Doll (JIRA) <ji...@apache.org>
> wrote:
>
> > Add a new method to SecurityToken - getContainer()
> > --------------------------------------------------
> >
> > Key: SHINDIG-635
> > URL: https://issues.apache.org/jira/browse/SHINDIG-635
> > Project: Shindig
> > Issue Type: New Feature
> > Components: Common Components (Java)
> > Reporter: Cassie Doll
> >
> >
> > I'd like to add a new method to the SecurityToken interface called
> > getContainer(). This will return the current container that is being
> > rendered. With the container and the ContainerConfig any consumers of the
> > SecurityToken interface can look up any parameter that they may need.
> >
> > Does anybody think this will be a problem?
> >
> > --
> > This message is automatically generated by JIRA.
> > -
> > You can reply to this email to add a comment to the issue online.
> >
> >
>
>
> --
> .-. --- .--. ..-
> R o p u
>
Re: [jira] Created: (SHINDIG-635) Add a new method to SecurityToken - getContainer()
Posted by Ropu <ro...@gmail.com>.
Hi Cassie, im working on the update of the way we user the ST in PHP.
Can you elaborate a little more on how will affect the code that uses de ST?
And obviously we need to update the way we generate it in the iframe url.
anything else?
thanks
ropu
On Tue, Sep 30, 2008 at 8:39 PM, Cassie Doll (JIRA) <ji...@apache.org> wrote:
> Add a new method to SecurityToken - getContainer()
> --------------------------------------------------
>
> Key: SHINDIG-635
> URL: https://issues.apache.org/jira/browse/SHINDIG-635
> Project: Shindig
> Issue Type: New Feature
> Components: Common Components (Java)
> Reporter: Cassie Doll
>
>
> I'd like to add a new method to the SecurityToken interface called
> getContainer(). This will return the current container that is being
> rendered. With the container and the ContainerConfig any consumers of the
> SecurityToken interface can look up any parameter that they may need.
>
> Does anybody think this will be a problem?
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
--
.-. --- .--. ..-
R o p u
Re: [jira] Commented: (SHINDIG-635) Add a new method to SecurityToken - getContainer()
Posted by Paul Lindner <pl...@hi5.com>.
Okay, I'm going to commit the modified interface for SecurityToken.
This means that implementers will need to either default to a
container value or round-trip container information in the security
token (see examples).
On Jan 23, 2009, at 3:03 PM, Brian Eaton wrote:
>> Anyone know if the 'domain' of a security token would suffice as
>> the container value?
>
> It doesn't. The domain is used for outbound signed fetch calls as the
> oauth_consumer_key value. Multiple containers might use the same
> consumer key. (For example, sandbox vs prod.)
Re: [jira] Commented: (SHINDIG-635) Add a new method to SecurityToken
- getContainer()
Posted by Brian Eaton <be...@google.com>.
> Anyone know if the 'domain' of a security token would suffice as the container value?
It doesn't. The domain is used for outbound signed fetch calls as the
oauth_consumer_key value. Multiple containers might use the same
consumer key. (For example, sandbox vs prod.)
[jira] Commented: (SHINDIG-635) Add a new method to SecurityToken -
getContainer()
Posted by "Paul Lindner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666802#action_12666802 ]
Paul Lindner commented on SHINDIG-635:
--------------------------------------
This code is now in trunk. domain does not equal container as per the mailing list.
I will now proceed with the @supportedFields changes
If this proves good we'll merge down to 1.0.x
> Add a new method to SecurityToken - getContainer()
> --------------------------------------------------
>
> Key: SHINDIG-635
> URL: https://issues.apache.org/jira/browse/SHINDIG-635
> Project: Shindig
> Issue Type: New Feature
> Components: Common Components (Java)
> Reporter: Cassie Doll
> Attachments: addGetContainerMethod.patch
>
>
> I'd like to add a new method to the SecurityToken interface called getContainer(). This will return the current container that is being rendered. With the container and the ContainerConfig any consumers of the SecurityToken interface can look up any parameter that they may need.
> Does anybody think this will be a problem?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-635) Add a new method to SecurityToken -
getContainer()
Posted by "Paul Lindner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666769#action_12666769 ]
Paul Lindner commented on SHINDIG-635:
--------------------------------------
Anyone know if the 'domain' of a security token would suffice as the container value?
> Add a new method to SecurityToken - getContainer()
> --------------------------------------------------
>
> Key: SHINDIG-635
> URL: https://issues.apache.org/jira/browse/SHINDIG-635
> Project: Shindig
> Issue Type: New Feature
> Components: Common Components (Java)
> Reporter: Cassie Doll
> Attachments: addGetContainerMethod.patch
>
>
> I'd like to add a new method to the SecurityToken interface called getContainer(). This will return the current container that is being rendered. With the container and the ContainerConfig any consumers of the SecurityToken interface can look up any parameter that they may need.
> Does anybody think this will be a problem?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SHINDIG-635) Add a new method to SecurityToken -
getContainer()
Posted by "Cassie Doll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cassie Doll updated SHINDIG-635:
--------------------------------
Attachment: addGetContainerMethod.patch
The BasicSecurityToken is the only token that doesn't have a container to expose already. If we want to add this in it shouldn't be too hard. Not sure if anyone needs it though.
> Add a new method to SecurityToken - getContainer()
> --------------------------------------------------
>
> Key: SHINDIG-635
> URL: https://issues.apache.org/jira/browse/SHINDIG-635
> Project: Shindig
> Issue Type: New Feature
> Components: Common Components (Java)
> Reporter: Cassie Doll
> Attachments: addGetContainerMethod.patch
>
>
> I'd like to add a new method to the SecurityToken interface called getContainer(). This will return the current container that is being rendered. With the container and the ContainerConfig any consumers of the SecurityToken interface can look up any parameter that they may need.
> Does anybody think this will be a problem?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SHINDIG-635) Add a new method to SecurityToken -
getContainer()
Posted by "Paul Lindner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul Lindner resolved SHINDIG-635.
----------------------------------
Resolution: Fixed
Fix Version/s: trunk
committed for a while now..
> Add a new method to SecurityToken - getContainer()
> --------------------------------------------------
>
> Key: SHINDIG-635
> URL: https://issues.apache.org/jira/browse/SHINDIG-635
> Project: Shindig
> Issue Type: New Feature
> Components: Java
> Reporter: Cassie Doll
> Fix For: trunk
>
> Attachments: addGetContainerMethod.patch
>
>
> I'd like to add a new method to the SecurityToken interface called getContainer(). This will return the current container that is being rendered. With the container and the ContainerConfig any consumers of the SecurityToken interface can look up any parameter that they may need.
> Does anybody think this will be a problem?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.