OAuth

[Renaud Bardet]

Hi there !

I was wandering if anybody had come with an OAuth library,

if not, I would have to build it myself, so in that case would anybody be interested in participating ?

I'm asking because I'm just discovering OAuth and I might not grasp all of the concept of it,

so doing it on my own would probably end up in yet another thing nobody would ever use again

[Franco Ponticelli]

This is a very interesting project and I don't know of any implementation so far. If you end up building your lib please share it if possible.

Franco

--
--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
 
 
 

[Renaud Bardet]

ok then,

I will post at http://code.google.com/p/hxoauth

[clemos]

Hi,

It would indeed be a great project.

The best way to go (since I don't have any real clue as to how to
structure this thing either) would probably be to port one of the
existing implementation:
https://code.google.com/p/oauth/
I only know the PHP one, which seems rather well done and probably portable...

Regards,
Clément

[Philippe Elsass]

Might be worth looking at a closer language, like JS:

http://oauth.net/code/ 

Philippe

[Renaud Bardet]

I'm begining to have a better comprehension of the thing by looking at other implementations (especially the python one found at http://pypi.python.org/pypi/oauth2/) and the RFC

My primary need is to implement the final step of the protocol,

when the client has (finally) retreived the token and just need to make authenticated requests,

because of my current project at work, we only use OAuth to discuss with static keys known both sides

so I'll start by the end, and will complete the project on my free time

Le mercredi 27 juin 2012 15:30:07 UTC+2, Renaud Bardet a écrit :

[Dion Whitehead Amago]

I use Haxe with Node.js and the everyauth library.  It's pretty comprehensive, and fairly easy to use, as these things go.

Dion

[Renaud Bardet]

Hey, first commit is here :  http://code.google.com/p/hxoauth/

So like I said earlier this only covers the following :

client :

- sending authenticated requests (no token request, you need both consumer key/secret and token key/secret)

- HTTP method GET (POST, PUT and DELETE will follow shortly)

- HMAC-SHA1 signature (RSA-SHA1 and PLAINTEXT are scheduled)

server :

not planned at the moment

I used a modified version of cafeinHx library for HMAC and SHA1

I also included a Base64 codec lib (this would be great to add to Std)

please tell me what you think of it so far !

you can test it by requesting to a sample server at term.ie (http://term.ie/oauth/example/index.php)

Regards,

Renaud

Le mercredi 27 juin 2012 15:30:07 UTC+2, Renaud Bardet a écrit :

[Tarwin Stroh-Spijer]

Great to see this!

What do people feel about optimizing for different targets. Specifically I do a lot of PHP stuff in haxe, and a lot of the methods have "native" implementations already. How do people feel about having a lot of #if php etc in non Std libraries like these?

Regards,


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
cell: +1 650 842 0920
_______________________

--

[Renaud Bardet]

Hi,

so, I've gone from using caffein-hx to haxe.SHA1 for encryption as I had weird behaviours in generating the signature,

it has been pushed on google code if you want to see it

I had to rewrite a HMAC class that could handle the specification of haxe.SHA1

thing is, I'm still having the same issues as with caffein-hx :

- result vary from plateform to plateform (tested on neko and flash)

- althought generated digest is valid for a simple key ( < 64 chars in length ) it is rubish when using a larger one (I compared with the result of php hash_hmac( "sha1", key, data ))

I can't seem to find the error in my implementation of HMAC and I tested SHA1 encoding on neko and flash with identical results so haxe.SHA1 is not the problem

I followed RFC for my implementation (http://tools.ietf.org/html/rfc2104) if anyone care to take a look

Tarwin, this can be a good solution when it really speeds up things, I might add some shortcuts once I'm sure the pure haXe version is stable

Le mercredi 27 juin 2012 15:30:07 UTC+2, Renaud Bardet a écrit :

[tom rhodes]

i'd be very interested in knowing how to do "php hash_hmac( "sha256", key, data ))" in haxe :)

i've had to use __call__ in php for that and base64url decoding very recently.

[Renaud Bardet]

Hi tom,

sorry I meant i ran hash_hmac in a index.php, written in php, like you know, without haxe ( yes i sufferd a lot from that )

Le mercredi 27 juin 2012 15:30:07 UTC+2, Renaud Bardet a écrit :

[Renaud Bardet]

Ah ok, I get it now, you were asking how to implement the equivalent of hash_hmac( "sha256", , ) in haXe...

well there is one implementation in caffein-hx, althought you might want to be cautious as their sha1 doesn't seem to perform so well

I don't know of any other implementation, but I might need to use one myself when implementing OAuth2 (its on my sheddule for hxoauth)

[Greg Dove]

I don't know if its relevant here , but the first thing I always suspect when getting differences between neko or php for example vs. flash when using byte related manipulation of strings is the default character encoding. I have had other occasions where I had to normalise everything to utf-8 to match flash behaviour.

--

[tom rhodes]

@Renauld: yup, exactly i have untyped { __call__("hash_hmac"............} etc. i didn't like caffeine because it decided it wanted to overwrite loads of other stuff, which caused type clashes. i might pull the code out of there and have a look with it being isolated. i'd really like to not have the php target specific code in there, but right now i can't see any other way.

i think Greg is right about he character encoding too though, would be good to have this consistent across targets if poss. 

[Greg Dove]

@Tom, fyi there is already support for conversions in haxe: http://haxe.org/api/haxe/utf8

Perhaps that is enough, because I expect that the default encoding on the other platforms provides performance benefits when utf8 is not needed, especially if a character always maps to a single byte.

[Jonas Malaco Filho]

Some time ago I did a quick (and dirty) HMAC implementation that worked well on neko/C++ with any size keys. If you wan't to take a look, you can find my implementation here. For JavaScript you'll have to work only with Bytes (since no binary data is supported on strings).