Login Generator with Extensible authorisation


#1

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?


#2

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

  • james

On 4/14/06, Rob B. removed_email_address@domain.invalid wrote:

removed_email_address@domain.invalid
http://lists.rubyonrails.org/mailman/listinfo/rails

  • J *
    ~

#3

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 B. 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?


#4

James A. wrote:

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

  • james

On 4/14/06, Rob B. removed_email_address@domain.invalid wrote:

removed_email_address@domain.invalid
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 #
… at the moment which makes me think ive gone very wrong some where!


#5

Steve K. 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


#6

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 L. wrote:

Steve K. 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


#7

Steve K. 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