javascript library for the security token

[Brian Eaton <be...@google.com>]

Hey folks -

I'd like to write a javascript library to manage the gadget security
token.  Code that calls gadgets.util.getUrlParameters().st would need
to change to call gadgets.auth.getSecurityToken().

This will let us do things like periodically update the security token.

Cheers,
Brian

Re: javascript library for the security token

[Brian Eaton <be...@google.com>]

On Fri, May 9, 2008 at 4:06 PM, Kevin Brown <et...@google.com> wrote:
>  Everything that's standardized can, of course, be depended on. The stuff
>  that isn't probably shouldn't be. One issue here is the lack of unit tests
>  for the javascript. There are a few people working on addressing this by
>  having a test runner that can be used to run jsunit tests.

It'd be nice to having something in between a blessed opensocial API
vs free-for-all-might-change-at-any-minute-code.  I'm thinking of
something like Mozilla's tagging of interfaces as frozen.

Re: javascript library for the security token

[Kevin Brown <et...@google.com>]

On Fri, May 9, 2008 at 1:34 PM, Brian Eaton <be...@google.com> wrote:

> On Fri, May 9, 2008 at 10:27 AM, Kevin Brown <et...@google.com> wrote:
> > This is probably useful, but I'm hesitant on the namespace -- if a
> >  standardized "auth" feature emerges, we'd have a conflict. I think this
> came
> >  up before. Perhaps we should make all shindig implementation packages
> name
> >  an underscore suffix to avoid this? Something like gadgets.auth_. We
> could
> >  even put it under the "shindig" namespace to really avoid conflicts (and
> we
> >  could migrate gadgets.config to this as well).
>
> I don't like gadgets.auth_, but shindig.auth sounds good to me.
> gadgets.securityToken or shindig.securityToken would be fine with me
> as well.
>
> One of my concerns about the javascript libraries in general is that
> it's a little unclear what Shindig integrators can and can't depend
> on.  If I pull the security token out of the URL, who am I going to
> break?  The java code is changing frequently, but at least it gives a
> compiler error when interfaces change.


Everything that's standardized can, of course, be depended on. The stuff
that isn't probably shouldn't be. One issue here is the lack of unit tests
for the javascript. There are a few people working on addressing this by
having a test runner that can be used to run jsunit tests.

Of course, that still doesn't help in situations like these. Compliance
tests like the opensocial compliance suite, which is just a gadget are
probably the right answer here.

Re: javascript library for the security token

[Brian Eaton <be...@google.com>]

On Fri, May 9, 2008 at 10:27 AM, Kevin Brown <et...@google.com> wrote:
> This is probably useful, but I'm hesitant on the namespace -- if a
>  standardized "auth" feature emerges, we'd have a conflict. I think this came
>  up before. Perhaps we should make all shindig implementation packages name
>  an underscore suffix to avoid this? Something like gadgets.auth_. We could
>  even put it under the "shindig" namespace to really avoid conflicts (and we
>  could migrate gadgets.config to this as well).

I don't like gadgets.auth_, but shindig.auth sounds good to me.
gadgets.securityToken or shindig.securityToken would be fine with me
as well.

One of my concerns about the javascript libraries in general is that
it's a little unclear what Shindig integrators can and can't depend
on.  If I pull the security token out of the URL, who am I going to
break?  The java code is changing frequently, but at least it gives a
compiler error when interfaces change.

Re: javascript library for the security token

[Cassie <do...@apache.org>]

btw - we -do- have jsunit tests. we aren't writing enough of them but
they do run.


On Mon, May 12, 2008 at 1:59 AM, Brian Eaton <be...@google.com> wrote:
> On Fri, May 9, 2008 at 10:27 AM, Kevin Brown <et...@google.com> wrote:
>> This is probably useful, but I'm hesitant on the namespace -- if a
>>  standardized "auth" feature emerges, we'd have a conflict. I think this came
>>  up before. Perhaps we should make all shindig implementation packages name
>>  an underscore suffix to avoid this? Something like gadgets.auth_. We could
>>  even put it under the "shindig" namespace to really avoid conflicts (and we
>>  could migrate gadgets.config to this as well).
>
> shindig.auth attached to https://issues.apache.org/jira/browse/SHINDIG-264
>
> Cheers,
> Brian
>

Re: javascript library for the security token

[Brian Eaton <be...@google.com>]

On Fri, May 9, 2008 at 10:27 AM, Kevin Brown <et...@google.com> wrote:
> This is probably useful, but I'm hesitant on the namespace -- if a
>  standardized "auth" feature emerges, we'd have a conflict. I think this came
>  up before. Perhaps we should make all shindig implementation packages name
>  an underscore suffix to avoid this? Something like gadgets.auth_. We could
>  even put it under the "shindig" namespace to really avoid conflicts (and we
>  could migrate gadgets.config to this as well).

shindig.auth attached to https://issues.apache.org/jira/browse/SHINDIG-264

Cheers,
Brian

Re: javascript library for the security token

[Kevin Brown <et...@google.com>]

This is probably useful, but I'm hesitant on the namespace -- if a
standardized "auth" feature emerges, we'd have a conflict. I think this came
up before. Perhaps we should make all shindig implementation packages name
an underscore suffix to avoid this? Something like gadgets.auth_. We could
even put it under the "shindig" namespace to really avoid conflicts (and we
could migrate gadgets.config to this as well).

On Fri, May 9, 2008 at 7:31 AM, Brian Eaton <be...@google.com> wrote:

> Hey folks -
>
> I'd like to write a javascript library to manage the gadget security
> token.  Code that calls gadgets.util.getUrlParameters().st would need
> to change to call gadgets.auth.getSecurityToken().
>
> This will let us do things like periodically update the security token.
>
> Cheers,
> Brian
>