I'm gonna try next week to combine with CanCan so i'll let you know - but I see no reason why not - CanCan doesn't care, and I don't see a reason why Sorcery will, as long that you are using the same User model.
If you check out Sorecery Wiki - external login you see that only FB and twitter are currently supported, but if you look at the migrations that are generated by external model, it should be easy to integrate it with another gem, like OmniAuth, then do OpenID authentication & callback from there. It is not pretty and, well, it might brake when either of them changes their DB structure or API, but until Sorcery will support it...
Maybe another idea for an episode is how to save sensitive data (API user/password keys, etc) in production environment, while not disturbing Capistrano deployments etc.?
+1
Good one:)
you can use
Alike, you can use request.headers['X-PJAX'] + parameters to determine what to render in templates too, if you feel like it
I'm gonna try next week to combine with CanCan so i'll let you know - but I see no reason why not - CanCan doesn't care, and I don't see a reason why Sorcery will, as long that you are using the same User model.
If you check out Sorecery Wiki - external login you see that only FB and twitter are currently supported, but if you look at the migrations that are generated by external model, it should be easy to integrate it with another gem, like OmniAuth, then do OpenID authentication & callback from there. It is not pretty and, well, it might brake when either of them changes their DB structure or API, but until Sorcery will support it...
Maybe another idea for an episode is how to save sensitive data (API user/password keys, etc) in production environment, while not disturbing Capistrano deployments etc.?
Or is it just me? :)
Great work, i've been using active merchant fork supporting PPR for express checkout, and this does seem like a much lighter solution.
Very nicely done :)
Ok, it seems like something that occurred in rails 3.1, that for some reason did not show its ugly face on normal rspec exec, but does on --drb.
mock_model should not be used with class name, rather it should be used with actual class now.
code is
Great screencast. But - on spork, some of my specs fail, that do not fail on local (non drb) testing. Anyone has ideas?? :(
It seems it has something to do with rspec mocking, example of one of the errors (repeating itself over the entire spec file)
Failure/Error: @order.station = mock_model("Station")
NoMethodError:
undefined method `primary_key' for Station:Class