add openid server for single signon auth for mapknitter & spectral-workbench

[jywarren]

masq : https://github.com/dennisreimann/masq/tree/master/config

https://github.com/icef/masq-app/tree/master/app/models/

has_one :masq_account, :class_name => 'Masq::Account'

OK, that didn't go so well. Now trying to start over using rails-openid and the example server here: https://github.com/openid/ruby-openid/tree/master/examples/rails_openid

[jywarren]

The server is now running :-)

Now we need to consider:

A. Old users who have SW and MK accounts and are authenticating through publiclaboratory.org and have a PublicLab.org account too B. Old users who have SW and MK accounts and are authenticating through publiclaboratory.org and DO NOT HAVE a PublicLab.org account yet C. Old users who do not yet have SW and MK accounts, and can use the new site to authenticate D. New users who can register at PublicLab.org and use it to authenticate for SW and MK as well

So, A) will need to be batch upgraded to new identity URLs... but B) will need to get PublicLab.org accounts before that'll work!!!

C) and D) will have no trouble.

Can we just automatically create PublicLab.org accounts for all of A and B?

[jywarren]

I believe I've a plan to deal with A and B above, though not ideally.

B users will be prompted to create a PublicLab.org account, but they will not be redirected back to SpectralWorkbench.org upon creating that account. We should try to fix that -- perhaps we can detect that there was an incoming request on account creation from SW, and have a notice that says "if you were trying to use SpectralWorkbench.org, click here to continue >>"

We also need to be sure users create a password for the new site. And as a backup plan, openid auth between PublicLaboratory.org and PublicLab.org should also work, by rewriting identity_urls to old.publiclab.org

Next step: track the session contents to see where we lose track of the original openid request from SW/MK. Potentially just record that there was an incoming openid request, and add the above notice upon PublicLab.org login. How many users will actually see this? Anyone using SpectralWorkbench.org who has not been aware of PublicLab.org, so quite a number of active users. Leave a web@pl address for them to contact.

[jywarren]

almost there... spectralworkbench is not receiving params in the last step of the process... need to adapt the technique to Rails 2.3, in that codebase:

   if params['openid.mode']
    oidreq = server.decode_request(params)
  else
    oidreq = server.decode_request(Rack::Utils.parse_query(request.env['ORIGINAL_FULLPATH'].split('?')[1]))
  end

[jywarren]

see output of publiclab.org log here: https://gist.github.com/jywarren/879e0b450a3b8a82fffa

spectralworkbench (local) says:

208302 Missing required parameter in response from http://publiclab.org/openid: <http://openid.net/signon/1.0>assoc_type not in this message
208303 Generated checkid_setup request to http://publiclab.org/openid using stateless mode.
208304 Using 'check_authentication' with http://publiclab.org/openid

and it received a whole html page from publiclab.org

and yay, the whole request in the final spectralworkbench.org (local) action:

https://gist.github.com/jywarren/df3671d5be11f9dfb9ce

[jywarren]

I believe this is a red herring. This openid response indicates that it's failing because the "SERVER_PORT" is 3001... something which will not be the case on a live deployment, but only when running locally at port 3001.

"rack.openid.response"=>#<OpenID::Consumer::FailureResponse:0xb6ef985c @message="Server http://publiclab.org/openid responds that the 'check_authentication' call is not valid", @contact=nil, @endpoint=#<OpenID::OpenIDServiceEndpoint:0xb6ebf530 @used_yadis=true, @server_url="http://publiclab.org/openid", @canonical_id=nil, @claimed_id="http://publiclab.org/openid/warren", @local_id=nil, @display_identifier=nil, @type_uris=["http://specs.openid.net/auth/2.0/signon", "http://openid.net/signon/1.0", "http://openid.net/sreg/1.0"]>, @reference=nil>, "SERVER_PORT"=>"3001", "PASSENGER_APP_SPAWNER_IDLE_TIME"=>"-1", "rack.request.cookie_string"=>"user_credentials=blablabla"