You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Adam Winer <aw...@google.com> on 2009/01/23 21:05:52 UTC
@supportedFields do-over, and "container" from SecurityToken?
I've attached a patch to SHINDIG-560 that reimplements
@supportedFields off of ContainerConfig, without using ContainerConf.
The major issue with it is that I'm unaware of an API in social-api
land to portably retrieve the container. The patch "solves" the
problem with a protected hook method in DataServiceServlet so a
container developer can implement custom logic. But that seems rather
lame. What do people think about a SecurityToken.getContainer()
method?
-- Adam
Re: @supportedFields do-over, and "container" from SecurityToken?
Posted by Paul Lindner <pl...@hi5.com>.
Applied, and the new container config code is also applied
Since most requests to /social/rest/[people|activities|..]/
@supportedFields will not have a secure token I added a way to make
anonymous tokens that have differing container values.
This will be a little tricky to implement. I'm thinking that
AnonymousAuthenticationHandler should pass in the value of HTTP_HOST
to the default tokendecoder instead of creating it's own
AnonymousToken().
Thoughts?
On Jan 23, 2009, at 12:20 PM, Adam Winer wrote:
> On Fri, Jan 23, 2009 at 12:13 PM, Kevin Brown <et...@google.com> wrote:
>> On Fri, Jan 23, 2009 at 12:05 PM, Adam Winer <aw...@google.com>
>> wrote:
>>
>>> I've attached a patch to SHINDIG-560 that reimplements
>>> @supportedFields off of ContainerConfig, without using
>>> ContainerConf.
>>>
>>> The major issue with it is that I'm unaware of an API in social-api
>>> land to portably retrieve the container. The patch "solves" the
>>> problem with a protected hook method in DataServiceServlet so a
>>> container developer can implement custom logic. But that seems
>>> rather
>>> lame. What do people think about a SecurityToken.getContainer()
>>> method?
>>
>>
>> Ha!
>>
>> https://issues.apache.org/jira/browse/SHINDIG-635
>
> Apply, apply! ;)
>
> -- Adam
>
>>
>>
>>>
>>>
>>> -- Adam
>>>
>>
Re: @supportedFields do-over, and "container" from SecurityToken?
Posted by Adam Winer <aw...@google.com>.
On Fri, Jan 23, 2009 at 12:13 PM, Kevin Brown <et...@google.com> wrote:
> On Fri, Jan 23, 2009 at 12:05 PM, Adam Winer <aw...@google.com> wrote:
>
>> I've attached a patch to SHINDIG-560 that reimplements
>> @supportedFields off of ContainerConfig, without using ContainerConf.
>>
>> The major issue with it is that I'm unaware of an API in social-api
>> land to portably retrieve the container. The patch "solves" the
>> problem with a protected hook method in DataServiceServlet so a
>> container developer can implement custom logic. But that seems rather
>> lame. What do people think about a SecurityToken.getContainer()
>> method?
>
>
> Ha!
>
> https://issues.apache.org/jira/browse/SHINDIG-635
Apply, apply! ;)
-- Adam
>
>
>>
>>
>> -- Adam
>>
>
Re: @supportedFields do-over, and "container" from SecurityToken?
Posted by Kevin Brown <et...@google.com>.
On Fri, Jan 23, 2009 at 12:05 PM, Adam Winer <aw...@google.com> wrote:
> I've attached a patch to SHINDIG-560 that reimplements
> @supportedFields off of ContainerConfig, without using ContainerConf.
>
> The major issue with it is that I'm unaware of an API in social-api
> land to portably retrieve the container. The patch "solves" the
> problem with a protected hook method in DataServiceServlet so a
> container developer can implement custom logic. But that seems rather
> lame. What do people think about a SecurityToken.getContainer()
> method?
Ha!
https://issues.apache.org/jira/browse/SHINDIG-635
>
>
> -- Adam
>