Forum: Ruby on Rails Login Generator with Extensible authorisation

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
F779209a7f02c754eda7b505898347f9?d=identicon&s=25 Rob Balfour (robtotheb)
on 2006-04-14 12:49
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?
05d703f649ef1d07e78d7b479fb4c4ac?d=identicon&s=25 James Adam (Guest)
on 2006-04-14 15:17
(Received via mailing list)
"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 *
  ~
34f5b045aec62235c17458650ea75353?d=identicon&s=25 Steve Koppelman (hatless)
on 2006-04-14 15:20
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?
D4e51fd9554030ab55c379fdc1a34826?d=identicon&s=25 Keith Lancaster (klancaster)
on 2006-04-14 15:33
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
F779209a7f02c754eda7b505898347f9?d=identicon&s=25 Rob Balfour (robtotheb)
on 2006-04-14 15:37
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!
F779209a7f02c754eda7b505898347f9?d=identicon&s=25 Rob Balfour (robtotheb)
on 2006-04-14 15:42
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
34f5b045aec62235c17458650ea75353?d=identicon&s=25 Steve Koppelman (hatless)
on 2006-04-14 16:23
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
This topic is locked and can not be replied to.