[oauth] Re: load testing an oAuth provider?

[Seth Fitzsimmons]

We tried this a while back, but it wasn't entirely clear whether we
were introducing new bottlenecks.  That said, the 2 approaches we
experimented with were:

* pre-generating a list of signed URLs and running them through httperf
* using oauth-proxy (http://github.com/mojodna/oauth-proxy) with
apachebench (httperf doesn't have proxy support) to sign URLs on the
fly.  oauth-proxy is a Twisted server, so it shouldn't have affected
concurrency numbers, but we didn't keep track of the overhead that the
signing introduced.

I was thinking that it might be useful to hack OAuth support into
JMeter in order to be able to use that, but never got that far.

I hope this helps.

seth

On Sun, Mar 22, 2009 at 4:49 PM, Perryn Fowler  wrote:
>
> Has anyone performed load testing on an oAuth provider? If so, what did you 
> use?
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Fwd: [Social] [Fwd: [Standards] UPDATED: XEP-0235 (OAuth Over XMPP)]

[Chris Messina]

FYI.

-- Forwarded message --
From: Peter Saint-Andre 
Date: Tue, 24 Mar 2009 17:13:02 -0700
Subject: [Social] [Fwd: [Standards] UPDATED: XEP-0235 (OAuth Over XMPP)]
To: "XMPP and Social Networking, Two Great Tastes That Taste Great
Together!" 

FYI. My apologies about the namespace change, but this means we won't
need to change it again when the spec advances to Draft.

Peter

 Original Message 
Subject: [Standards] UPDATED: XEP-0235 (OAuth Over XMPP)
Date: Tue, 24 Mar 2009 19:10:22 -0500
From: XMPP Extensions Editor 
Reply-To: XMPP Standards 
To: standa...@xmpp.org

Version 0.7 of XEP-0235 (OAuth Over XMPP) has been released.

Abstract: This specification defines an XMPP extension for delegating
access to protected resources over XMPP, using the OAuth protocol. In
the language of OAuth, a User can authorize a Consumer to access a
Protected Resource that is hosted by a Service Provider; this
authorization is encapsulated in a token that the User requests from the
Service Provider, that the User shares with the Consumer, and that the
Consumer then presents to the Service Provider in an access request.
This specification assumes that OAuth tokens will be acquired via HTTP
as defined in the core OAuth specification, then presented over XMPP to
a Service Provider. The Protected Resources accessible over XMPP might
include groupchat rooms, data feeds hosted at publish-subscribe nodes,
media relays, communication gateways, and other items of interest.

Changelog: Changed protocol namespace from urn:xmpp:tmp:oauth to
urn:xmpp:oauth:0 to conform to XMPP Registrar policies; clarified
protocol flow and error handling; corrected examples. (psa)

Diff:
http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0235.xml?%40diffMode=u&%40diffWrap=s&r1=2146&r2=2920&u=3&ignore=&k=

URL: http://www.xmpp.org/extensions/xep-0235.html


-- 
Peter Saint-Andre
https://stpeter.im/




-- 
Chris Messina
Citizen-Participant &
  Open Web Advocate

factoryjoe.com // diso-project.org // vidoop.com
This email is:   [ ] bloggable[X] ask first   [ ] private

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Security through obscurity?

[Mark Wubben]

On Mar 23, 2009, at 12:19 , Nial wrote:
> It seems like the best way to move forward would be to have my widget
> contact my server and check for a change in consumer key/secret. Of
> course, it'd be easy for anyone to visit that address for the latest
> details, but it'd mean less hassle for the end-user.

This may be less relevant in this particular discussion, but if you're  
dealing with web-based widgets, a server call could be used to  
authenticate the Consumer without using a secret. I wrote down some  
ideas about a potential solution here:



--
Mark Wubben

http://supercollider.dk


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Java client using HttpClient AuthScheme

[jmkristian]

OAuth parameters may be placed in an Authenticate header or a URL
query string, but not both. http://oauth.net/core/1.0#consumer_req_param
OAuthScheme could contain an OAuth.ParameterStyle to determine where
it places OAuth parameters.  If they go in the query string, I guess
it would do something like request.setURI(OAuth.addParameters
(request.getURI(), ...)).  The query string's not a header, I think.

I don't know a good reason to support parameters in a PUT body.  I
don't know any applications that do this.  OAuth doesn't specify how
applications send their parameters.

On Mar 23, 11:12 am, Paul Austin  wrote:
> Does the OAuth spec support using the PUT body?
>
> I think it should be possible to add the parameters to the query
> string also. For this you would get the query string request header
> (for GET) and then add the parameters and then set the header to the
> new value. The OAuthSchemeFactory could have boolean properties which
> would allow the user to select using the Authenticate header, the
> query string, or both.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---