Rails - Apr 2006 - Login Generator with Extensible authorisation

I want my web app to have a signup/login generator but have 2 tiers of 
users - normal and premium.  There seems to be lots of login generator 
and engines with scattered tutorials about extensible authorisation and 
Im lost as which is the ''best'' or most ''easy to
use'' solution.  Anyone
had success in this area?

-- 
Posted via http://www.ruby-forum.com/.

"Best" is pretty subjective, Rob. What sort of things are important to
you?

- james

On 4/14/06, Rob Balfour <rob_uk88@hotmail.com>
wrote:
> I want my web app to have a signup/login generator but have 2 tiers of
> users - normal and premium.  There seems to be lots of login generator
> and engines with scattered tutorials about extensible authorisation and
> Im lost as which is the ''best'' or most ''easy to
use'' solution.  Anyone
> had success in this area?
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

--
* J *
  ~

The two that seem to be under most active development and use right now 
are the LoginEngine/UserEngine combo from rails-engines.org, and 
ActiveRBAC, which is also an engine. I use the former. It''s a bit rough
around the edges and the administration UI is pretty Spartan, but the 
lead developer seems to stay on top of things when there are problems, 
and it works as advertised. ActiveRBAC seems to be well-liked by people 
on this list lately, too, and has nice documentation.

However, because they override built-in Rails behaviors, security 
plugins are sensitive to changes in the Rails API. If the experience of 
going from Rails 1.0 to 1.1 with the Engines plugin is any indication, 
it''s going to be especially important down the road to make sure the 
engines you''re using -- and the Engines plugin itself -- have made the 
transition to a given new version of Rails before you migrate an app to 
it.

Rob Balfour wrote:
> I want my web app to have a signup/login generator but have 2 tiers of 
> users - normal and premium.  There seems to be lots of login generator 
> and engines with scattered tutorials about extensible authorisation and 
> Im lost as which is the ''best'' or most ''easy to
use'' solution.  Anyone
> had success in this area?

-- 
Posted via http://www.ruby-forum.com/.

Steve Koppelman wrote:
> However, because they override built-in Rails behaviors, security 
> plugins are sensitive to changes in the Rails API. If the experience of 
> going from Rails 1.0 to 1.1 with the Engines plugin is any indication, 
> it''s going to be especially important down the road to make sure
the
> engines you''re using -- and the Engines plugin itself -- have made
the
> transition to a given new version of Rails before you migrate an app to 
> it.
> 
Due in part to the issue Steve mentions above, we recently abandoned the 
user/login engine combination as well as the generators and moved to 
writing our own implementation (based on the Rails Recipes book from 
PragProg). The other reason was that for our particular needs, we would 
have to modify / override a good bit of the engine functionality. It was 
easier to just code it from scratch (which took all of 3 hours to get 
basic authentication/authorization in place).

As somewhat of an aside, the interaction of plugins both with Rails and 
with each other is going to continue to be an issue unless there is some 
effort to freeze the portions of rails in someway that these plugins 
interact with. This could take the form of guidelines, like "Override 
this at your peril", or an api of some sort that is guaranteed to be 
backward compatible. Virtually every plugin we used was completely 
broken, at least initally, by upgrading Rails to 1.1, and there is no 
central place to go to see which plugins are compatible, etc. This cost 
us almost a week of work trying to iron everything out.

Keith

-- 
Posted via http://www.ruby-forum.com/.

James Adam wrote:
> "Best" is pretty subjective, Rob. What sort of things are
important to
> you?
> 
> - james
> 
> On 4/14/06, Rob Balfour <rob_uk88@hotmail.com> wrote:
>> Rails@lists.rubyonrails.org
>> http://lists.rubyonrails.org/mailman/listinfo/rails
>>
> 
> 
> --
> * J *
>   ~
I would like users to be able to sign up with email confirmation and 
password retrieval.  And have 2 user groups - normal members and paid 
members, each having their own permissions.

Ive been trying to get the login engine to work today but its proving 
difficult, Im getting:
SyntaxError in <controller not set>#<action not set>
.. at the moment which makes me think ive gone very wrong some where!

-- 
Posted via http://www.ruby-forum.com/.

Steve Koppelman wrote:
> Due in part to the issue Steve mentions above, we recently abandoned the 
> user/login engine combination as well as the generators and moved to 
> writing our own implementation (based on the Rails Recipes book from 
> PragProg). The other reason was that for our particular needs, we would 
> have to modify / override a good bit of the engine functionality. It was 
> easier to just code it from scratch (which took all of 3 hours to get 
> basic authentication/authorization in place).
> 
> As somewhat of an aside, the interaction of plugins both with Rails and 
> with each other is going to continue to be an issue unless there is some 
> effort to freeze the portions of rails in someway that these plugins 
> interact with. This could take the form of guidelines, like "Override 
> this at your peril", or an api of some sort that is guaranteed to be 
> backward compatible. Virtually every plugin we used was completely 
> broken, at least initally, by upgrading Rails to 1.1, and there is no 
> central place to go to see which plugins are compatible, etc. This cost 
> us almost a week of work trying to iron everything out.
> 
> Keith
Ive looked into getting rails receipes but wasn''t sure it covered what
I
needed.  guess i was wrong

-- 
Posted via http://www.ruby-forum.com/.

I agree it would be a great idea if RoR got a standardized
Plguin-Friendly API that could be set in stone in order to offer
developers a roadmap for forward-compatibility. And for good measure, 
maybe the Engines plugin should be cleaned up and merged into Rails.

Keith Lancaster wrote:
> Steve Koppelman wrote:
> 
>> However, because they override built-in Rails behaviors, security 
>> plugins are sensitive to changes in the Rails API. If the experience of
>> going from Rails 1.0 to 1.1 with the Engines plugin is any indication
>> ....
>> 
> 
> Due in part to the issue Steve mentions above, we recently abandoned the 
> user/login engine combination as well as the generators and moved to 
> writing our own implementation (based on the Rails Recipes book from 
> PragProg). 
:: snip ::
> As somewhat of an aside, the interaction of plugins both with Rails and 
> with each other is going to continue to be an issue unless there is some 
> effort to freeze the portions of rails in someway that these plugins 
> interact with. This could take the form of guidelines, like "Override 
> this at your peril", or an api of some sort that is guaranteed to be 
> backward compatible. Virtually every plugin we used was completely 
> broken, at least initally, by upgrading Rails to 1.1, and there is no 
> central place to go to see which plugins are compatible, etc. This cost 
> us almost a week of work trying to iron everything out.
> 
> Keith
-- 
Posted via http://www.ruby-forum.com/.