Great! I am just a little bit worried that the core is getting too
big.
The OAuth lib itself builds fine but sometimes we embed OAuth library
in other JARs. The build error occurs in a JMeter plugin for OAuth. We
build the plugin with OAuth code so only one JAR is delivered. For use-
cases like
To minimize dependencies, I recommend removing Java packages that you
don't need. You can eliminate several dependencies this way, such as
the Java Servlet API and both Apache HTTP client libraries.
I'm thinking of moving parts of oauth-core into new modules; for
example a module for consumers
Hi Zhihong
it's very important to keep the dependencies to a
minimum.
have you had the possibility to take a look at our OAuth Framework?
http://asmx-oauth.googlecode.com/svn/site/1.0/index.html
I'm already in touch with John and tomorrow we'll have a call to study
strategies together.
Best
Great -- just what I was hoping to hear. I didn't want to start
implementing if there was a known deal-breaker that I was not seeing.
The caveats you mention, while important, are not deal breakers give
what we need.
--peter
On Apr 15, 12:48 am, Mike Malone mjmal...@gmail.com wrote:
Yea, that
It's also similar to the way Amazon S3 URIs work, except with S3 the
timestamp is actually the expiration date for the URI (as opposed to the
time that the request was created) and there's no nonce (URIs can be used
repeatedly until they expire). You may want to take a look at their API for
some
If you want to use standard OAuth libraries, use a full set of
credentials: consumer key and consumer secret, token and token
secret. It's more than you need, but some libraries require it all.
If you need help using a specific library, this is a pretty good place
to ask.
On Apr 14, 10:32 pm,
