Hi Guys,
I am getting the following error message while trying to access
"OAuthAccessToken".
"Sorry, there seems to be a problem. The service you're looking for is
temporarily unavailable. We're working hard to restore your access as
soon as possible. Please try again in a few hours. Thanks for
Hey John -
A while back I needed to tack OAuth support on to a general purpose
HTTP client API. The goals were two-fold:
1) Do magic whenever possible. Request token and access token
requests happen under the covers. Adding the session extension
support was magic, it required no changes to ca
I propose to extend the Java oauth-core library to better support
accessing protected resources, as follows. Please let me know if this
is a bad idea, or there's a better way.
In brief, I propose to add a method to OAuthClient:
/** Send a request and return the response. */
public OAuthResponse
It's unusual for software to send a request to OAuthAuthorizeToken.
That URL is meant for browsing; that is, its server uses HTML to
present a user interface, to enable the user to log in to Google
(authenticate) and give permission for an application to access her
data (authorize).
http://code.g
The scalable oauth extension addresses multiple/additional resource
authorizations using the same tokens:
http://oauth.pbwiki.com/ScalableOAuth
- Praveen
On Fri, Jan 30, 2009 at 9:08 AM, Krishna Sankar (ksankar) wrote:
>
> Interesting ...
>
> IMHO, the scope (of the URL) determines the extend o
Interesting ...
IMHO, the scope (of the URL) determines the extend of capabilities
exposed (or can be accessed) via an OAuth mechanism. (I am working on a
few combinations of this to figure out the granularity)
So if we say the scope as www.example.com/uc/vmail/1234, then only the
voice mail #1
Most of the major providers that I know use SSL behind netscalars too
for their login servers. Usually netscalers persist the connections
with the origin servers so there is still huge performance improvement
while securing the data in transit in the internal network.
Of course passwords still hav
I'll start with the IPR question. The IETF has a very simple set of rules with
regard to its IPR policies. The full rules are available at:
https://datatracker.ietf.org/ipr/about/. In general, everyone is an individual,
and most of the IPR requirements are about copyrights. There is a disclosure
I'm not sure I completely understand, but what resources (and how
many) that you can access with an authorized token are outside the
spec.
OAuth is a generic method for protecting resources; it's up to you to
determine what, and for how long, you make those resources available.
Chris
On 1/30/09
Thank you both for your fast replies.
Indeed, I was wrong when I said that the distinction between both
tokens would dramatically increase the response time. I misunderstood
the spec, as I thought that one pair Request Token -- Access Token
only granted access to one protected resource (namely, o
Agreed. I don't think this solution works for everyone.
Though from that post it seems that unless the site is using SRP the
password is going in clear-text over the wire (SSL) for sites that store
salted hashes. (I just used Live HTTP headers to verify a major online
service provider and this
11 matches
Mail list logo
