django - Testing django_openid_provider -


i'm using django-openid-provider (https://bitbucket.org/romke/django_openid_provider/) , need test it's features before deploying on real server. i've tried construct post request documentation of openid 2.0 , send django's test server openid token.

my post looks so:

http://192.168.232.151:8008/openid/ 

body:

openid.ns:http://specs.openid.net/auth/2.0 openid.mode:associate openid.assoc_type:hmac-sha256 openid.session_type:dh-sha256 

also tried provide public key (such openid.dh_modulus, openid.dh_gen, openid.dh_consumer_public) diffie-hellman algorythm, , sniffing traffic of openid authentication additional keys in request, allways got 500 internal server error

exception type: protocolerror exception value:     no mode value in message <openid.message.message {('http://openid.net/signon/1.0', u'ns:http://specs.openid.net/auth/2.0\nopenid.mode:associate\nopenid.assoc_type:hmac-sha256\nopenid.session_type:dh-sha256'): u'dh-sha256eabv%252bfeozlgh%252beu71rlineppkiux\nopenid.dh_modulus:anz5oguioxlsdhmymswizjeohtdxfo2vcbt2i3myzuye91ouj4mlbx%2bykcliemocpym2cbryhnoyyjmg0mg3bvd9rcln5s3ihhoxghblzqdlfei%2f368ygo79jrnxtkxjgmy0rxlj5bu1zikasdukdii%2bxukkjx8fvf8w8vsixyor\nopenid.dh_gen:ag%3d%3d\nopenid.dh_consumer_public:ajs12o5ypo2n%2fl0rjiiogu9llg2dfsnjthyh49dx6fxz52idxnks7gquom6ker%2buftmktyvma5drzwj%2brx1jk7skmxjmmi9%2b7n5fa0wvz%2fi6nrvg8oqw31kh%2btbd9ansueatslcfuorcqeuheabv%2bfeozlgh%2beu71rlineppkiux'}> 

debugging django-openid module i've discovered constructing message object raises error can not find values of parameters satisfy openid-provider server

please show me i'm doing wrong? choosing hard way, can use emulates consumer site openid-client locally. or maybe have correct example of such post request? thanks

you best off using publicly accessible openid consumer or openid client library test django-openid-provider, since constructing openid request manually inconvenient.

in past, i've used mod_auth_openid (an apache module) testing against django_openid_provider, works well.

if intent on manually providing http requests against openid endpoint:

openid uses requests, not post requests.

the parameters should passed in query string, not in body.

using httpie, here's example of valid request against openid provider , assuming:

  • the openid endpoint http://192.168.232.151:8008/openid/
  • you've used django-openid-provider create openid called myopenid
  • the openid consumer (relaying party) http://www.example.com/protected/
  • the openid consumer protected using mod_auth_openid

here's initial request:

$ http http://192.168.232.151:8008/openid/ \ openid.assoc_handle=={hmac-sha256}{42a4370e}{g804lq====} \ openid.claimed_id==http://192.168.232.151:8008/openid/myopenid/ \ openid.identity==http://192.168.232.151:8008/openid/myopenid/ \ openid.mode==checkid_setup \ openid.ns==http://specs.openid.net/auth/2.0 \ openid.realm==http://www.example.com/protected/ \ openid.return_to==http://www.example.com/protected/?modauthopenid.nonce=qagqlncdll \ openid.trust_root==http://www.example.com/protected/ 

this equivalent to:

$ curl http://192.168.232.151:8008/openid/?openid.assoc_handle=%7bhmac-sha256%7d%7b42a4370e%7d%7bg804lq%3d%3d%3d%3d%7d&openid.claimed_id=http%3a%2f%2f192.168.232.151%3a8008%2fopenid%2fmyopenid%2f&openid.identity=http%3a%2f%2f192.168.232.151%3a8008%2fopenid%2fmyopenid%2f&openid.mode=checkid_setup&openid.ns=http%3a%2f%2fspecs.openid.net%2fauth%2f2.0&openid.realm=http%3a%2f%2fwww.example.com%2fprotected%2f&openid.return_to=http%3a%2f%2fwww.example.com%2fprotected%2f%3fmodauthopenid.nonce%3dqagqlncdll&openid.trust_root=http%3a%2f%2fwww.example.com%2fprotected%2f 

note openid.assoc_handle , modauthopenid.nonce values not valid in example, you'd have generate proper values those.

if succeeds, server should redirect via 302 http://www.example.com/protected/ number of query parameter arguments.

also note initial step in protocol, there additional requests involved.

but don't want manually craft these openid http requests. use openid library or openid consumer instead.


Comments