inject anonymous token via gadgets.config + shindig.auth in container mode

this is a first pass at adding an anonymous container token to the container javascript output.

Doing this I realized a few things:

* gadgets.config code for shindig.auth is broken.  (requests shindig.auth when feature is named core.auth)

* We should probably make a GadgetConfigContributor class that can dynamically change this via code.  Could be implemented as a map Multibinding of feature->contributorclass

[Paul Lindner, 2010-06-03 19:27:05]

curious if this approach is the correct way to go...

[fargo, 2010-06-07 12:11:43]

Just reviewing the concept, so I'll comment here.

On Fri, Jun 4, 2010 at 12:57 AM, <lindner@inuus.com> wrote:

> Reviewers: mhermanto, fargo, shindig.remailer_gmail.com,
>
> Message:
> curious if this approach is the correct way to go...
>
>
> Description:
> this is a first pass at adding an anonymous container token to the
> container javascript output.
>

So this is for what purpose exactly? The token is typically just used by the
gadget (gadgets.io.makeRequest, opensocial.* calls).


>
> Doing this I realized a few things:
>
> * gadgets.config code for shindig.auth is broken.  (requests
> shindig.auth when feature is named core.auth)
>

Seems like a pretty obvious fix on this one.


>
> * We should probably make a GadgetConfigContributor class that can
> dynamically change this via code.  Could be implemented as a map
> Multibinding of feature->contributorclass
>

You and your multibinders. Map is certainly better than Set! :) There are
still ordering issues when you have multiple contributors, but I could live
with this.

--j


>
>
>
> Please review this at http://codereview.appspot.com/1523041/show
>
> Affected files:
>  features/src/main/javascript/features/container/feature.xml
>  M
> java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/JsServlet.java
>
>
> Index: features/src/main/javascript/features/container/feature.xml
> diff --git a/features/src/main/javascript/features/container/feature.xml
> b/features/src/main/javascript/features/container/feature.xml
> index
>
ec5209bcaa7c331db218e08a41ceb7ab4910962f..d96fa8007e8d0fc0d5af7e3236539072dc8327fa
> 100644
> --- a/features/src/main/javascript/features/container/feature.xml
> +++ b/features/src/main/javascript/features/container/feature.xml
> @@ -21,6 +21,7 @@ under the License.
>   <name>container</name>
>   <dependency>globals</dependency>
>   <dependency>core.log</dependency>
> +  <dependency>core.auth</dependency>
>   <dependency>core.util</dependency>
>   <dependency>osapi</dependency>
>   <dependency>rpc</dependency>
> Index:
> java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/JsServlet.java
> diff --git
> a/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/JsServlet.java
> b/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/JsServlet.java
> index
>
fed4f9e1baf16f7c741812427220dc928bad3f2f..ca857cfed2d8877e70cdfc6b6330cd2fdcb369c4
> 100644
> ---
> a/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/JsServlet.java
> +++
> b/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/JsServlet.java
> @@ -23,6 +23,10 @@ import com.google.common.collect.Maps;
>
>  import org.apache.commons.lang.StringEscapeUtils;
>  import org.apache.commons.lang.StringUtils;
> +import org.apache.shindig.auth.AnonymousSecurityToken;
> +import org.apache.shindig.auth.SecurityToken;
> +import org.apache.shindig.auth.SecurityTokenDecoder;
> +import org.apache.shindig.auth.SecurityTokenException;
>  import org.apache.shindig.common.JsonSerializer;
>  import org.apache.shindig.common.servlet.HttpUtil;
>  import org.apache.shindig.common.servlet.InjectedServlet;
> @@ -35,6 +39,7 @@ import
> org.apache.shindig.gadgets.features.FeatureRegistry;
>  import org.apache.shindig.gadgets.features.FeatureResource;
>
>  import com.google.inject.Inject;
> +import org.json.simple.JSONObject;
>
>  import java.io.IOException;
>  import java.util.Collection;
> @@ -76,6 +81,12 @@ public class JsServlet extends InjectedServlet {
>     this.containerConfig = containerConfig;
>   }
>
> +  private SecurityTokenDecoder securityTokenCodec;
> +  @Inject
> +  public void setSecurityTokenCodec(SecurityTokenDecoder
> securityTokenCodec) {
> +    this.securityTokenCodec = securityTokenCodec;
> +  }
> +
>   @Override
>   protected void doGet(HttpServletRequest req, HttpServletResponse resp)
>       throws IOException {
> @@ -143,7 +154,7 @@ public class JsServlet extends InjectedServlet {
>     if (context == RenderingContext.CONTAINER) {
>       // Append some container specific things
>
> -      Map<String, Object> features =
> containerConfig.getMap(ctx.getContainer(), "gadgets.features");
> +      Map<String, Object> features = containerConfig.getMap(container,
> "gadgets.features");
>       Map<String, Object> config = Maps.newHashMapWithExpectedSize(features
> == null ? 2 : features.size() + 2);
>
>       if (features != null) {
> @@ -153,6 +164,20 @@ public class JsServlet extends InjectedServlet {
>           if (conf != null) {
>             config.put(name, conf);
>           }
> +          // Generate a default auth token
> +          if ("core.auth".equals(name)) {
> +            // Inject an anonymous security token TODO set TTL based on
> cachability of this JS?
> +            SecurityToken containerToken = new
> AnonymousSecurityToken(ctx.getContainer(),0,"*", 1000L * 60 * 60 * 24);
> +            JSONObject authconfig = new JSONObject();
> +            config.put("core.auth", authconfig);
> +
> +            try {
> +              authconfig.put("authToken",
> securityTokenCodec.encodeToken(containerToken));
> +
> +            } catch (SecurityTokenException e) {
> +              // ignore
> +            }
> +          }
>         }
>
>
jsData.append("gadgets.config.init(").append(JsonSerializer.serialize(config)).append(");\n");
>       }
>
>
>

[Paul Lindner, 2010-06-07 21:55:23]

>
> Description:
>> this is a first pass at adding an anonymous container token to the
>> container javascript output.
>>
>
> So this is for what purpose exactly? The token is typically just used by
> the gadget (gadgets.io.makeRequest, opensocial.* calls).
>

When using the common-container you need to make a json-rpc call.  This will
provide a default security token to use for that call.



>
>> Doing this I realized a few things:
>>
>> * gadgets.config code for shindig.auth is broken.  (requests
>> shindig.auth when feature is named core.auth)
>>
>
> Seems like a pretty obvious fix on this one.
>

Yes, fixing.

* We should probably make a GadgetConfigContributor class that can
>> dynamically change this via code.  Could be implemented as a map
>> Multibinding of feature->contributorclass
>>
>
> You and your multibinders. Map is certainly better than Set! :) There are
> still ordering issues when you have multiple contributors, but I could live
> with this.
>
>
Ordering will be the same as the feature ordering which sorts based on
javascript dependency ordering.

[fargo, 2010-06-08 10:23:06]

Ah yes, funky but worthwhile. I like the multibinder idea for this.

On Tue, Jun 8, 2010 at 3:25 AM, Paul Lindner <lindner@inuus.com> wrote:

> Description:
>>> this is a first pass at adding an anonymous container token to the
>>> container javascript output.
>>>
>>
>> So this is for what purpose exactly? The token is typically just used by
>> the gadget (gadgets.io.makeRequest, opensocial.* calls).
>>
>
> When using the common-container you need to make a json-rpc call.  This
> will provide a default security token to use for that call.
>
>
>
>>
>>> Doing this I realized a few things:
>>>
>>> * gadgets.config code for shindig.auth is broken.  (requests
>>> shindig.auth when feature is named core.auth)
>>>
>>
>> Seems like a pretty obvious fix on this one.
>>
>
> Yes, fixing.
>
> * We should probably make a GadgetConfigContributor class that can
>>> dynamically change this via code.  Could be implemented as a map
>>> Multibinding of feature->contributorclass
>>>
>>
>> You and your multibinders. Map is certainly better than Set! :) There are
>> still ordering issues when you have multiple contributors, but I could live
>> with this.
>>
>>
> Ordering will be the same as the feature ordering which sorts based on
> javascript dependency ordering.
>
>