> On 2012-02-29 21:43:25, Henry Saputra wrote: > > http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/oauth2/BasicOAuth2Request.java, > > line 563 > > <https://reviews.apache.org/r/3987/diff/2/?file=86671#file86671line563> > > > > Wouldnt we want to check for forbidden?
>From talking to Adam and reading the spec, no. >http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-16#section-3.1 insufficient_scope The request requires higher privileges than provided by the access token. The resource server SHOULD respond with the HTTP 403 (Forbidden) status code and MAY include the "scope" attribute with the scope necessary to access the protected resource. Basically this means that even if we got a new token we still wouldn't have permissions. It's not that the token is bad (in fact it's a valid access token), we simply don't have permissions to access the resource. In the 403 case the user could get a new token but the request would still fail. - Stanton ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/3987/#review5469 ----------------------------------------------------------- On 2012-02-29 21:30:23, Stanton Sievers wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/3987/ > ----------------------------------------------------------- > > (Updated 2012-02-29 21:30:23) > > > Review request for shindig, li xu and Adam Clarke. > > > Summary > ------- > > From JIRA: > If the url to which a gadget is doing a makeRequest doesn't exist, i.e., > returns a 404 to the Shindig server, the access token is being removed from > the OAuth2 Store. This functionality is implemented here: > org.apache.shindig.gadgets.oauth2.BasicOAuth2Request.fetchFromServer(OAuth2Accessor, > HttpRequest) > > fetchFromServer is checking only if the response code is 4xx, and if so, it > is removing the access token from the store. This seems right for 401 or 403 > return codes, perhaps, but not for 404. The behavior for an end user would > then be that they have to do the OAuth dance again next time the gadget tries > to access a resource. > > The proposal is to change the current implementation to look explicitly for > 401 or 403 response codes in fetchFromServer instead of looking for any 4xx. > > Any other recommendations on what the behavior should be are welcome. > > > This addresses bug SHINDIG-1711. > https://issues.apache.org/jira/browse/SHINDIG-1711 > > > Diffs > ----- > > > http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/oauth2/BasicOAuth2Request.java > 1295256 > > Diff: https://reviews.apache.org/r/3987/diff > > > Testing > ------- > > Built and ran existing JUnits. > > > Thanks, > > Stanton > >
