Hi, Can someone point me in a direction where I can learn more about handling athentication in a Rails app? I''m thinking about having an administrator belonging to one or more admin groups. Each admin group having it''s own set of privilages that might overlap. Thanks, Peter _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Hi Peter- I am implementing an authentication system in an app I''m working on, too. I started with the SaltedHashLoginGenerator as a start but then modified it for my purposes. I basically decided that any login generator would not be ideal for my purposes. Rather than working around it, I''d use it as a base. The biggest disadvantage to this approach is losing track of updates with the main core. Specifically, I have added AccountGroups which define priviledge classes. Each account, then belongs to exactly one AccountGroup. Jake _____ From: Peter Michaux [mailto:petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org] Sent: Thursday, November 10, 2005 12:00 AM To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org Subject: [Rails] Athentication Hi, Can someone point me in a direction where I can learn more about handling athentication in a Rails app? I''m thinking about having an administrator belonging to one or more admin groups. Each admin group having it''s own set of privilages that might overlap. Thanks, Peter _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Hi Peter and Jake, I am implementing a similar scenario on one of the projects I am working on. I am also implementing the same concept of account groups. Regards Dibya Prakash On 11/10/05, Jake Janovetz <jake-LtUAOcpEmBFWk0Htik3J/w@public.gmane.org> wrote:> > Hi Peter- > I am implementing an authentication system in an app I''m working on, too. > I started with the SaltedHashLoginGenerator as a start but then modified it > for my purposes. I basically decided that any login generator would not be > ideal for my purposes. Rather than working around it, I''d use it as a base. > The biggest disadvantage to this approach is losing track of updates with > the main core. > Specifically, I have added AccountGroups which define priviledge classes. > Each account, then belongs to exactly one AccountGroup. > Jake > > ------------------------------ > *From:* Peter Michaux [mailto:petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org] > *Sent:* Thursday, November 10, 2005 12:00 AM > *To:* rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > *Subject:* [Rails] Athentication > > Hi, > > Can someone point me in a direction where I can learn more about handling > athentication in a Rails app? I''m thinking about having an administrator > belonging to one or more admin groups. Each admin group having it''s own set > of privilages that might overlap. > > Thanks, > Peter > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Is it just me or is the number and variation of the various login/security systems a bit disturbing. The debate on what system to use has been on this list for a long time. So I thought I''d add my $0.02 as well ;) Before I do though, my hat goes off to the guys who have written these. There are some clever bits in all of them. I have been looking at all the different systems that I have been able to find and they are all so different I am hesitant to implement any of them. I''m no security expert so I don''t really feal comfortable coding my own in case I miss something stupid. The ones that I have tried are Login Generator - GENERATOR Salted hash login generator - GENERATOR Model Security - GENERATOR Active RBAC - COMPONENT Login Engine - ENGINE/PLUGIN These are either too complicated for my purposes, too simple, or just plain un-updateable. I''ve read on the list that this is the case for many people who, in the end write their own. This concerns me that there are so many out there with no common interfacefor the simple everyday (almost every app) tasks like setting filters and handling the login function, roles etc that it forces people to roll their own, taking these apps further away from any kind of standard in this area. Not very DRY. If I write an app around one system, and then decide to use another, I will most likely have to perform major surgery on my code. In addition to the fact that these login systems do no play nicely, is that most are geneators. Once I generate it, I almost certainly need to tailor it for my app, but when I do this, it''s no longer updateable. This has really made me look elsewhere above all other problems. If there is a security flaw identified in one of these systems after implementation, then how the hell, short of re-writing it do I fix it? (as I said, I''m not a security expert) The configuration setup for ActiveRBAC is very complicated and I have to mash the download (I''m on windows so no links) every different app I want to put it into. I like the idea of the engine/plugin. I can extend the model and controllers to suit my app without upsetting the base install, and I can also update it whenever I need/want to. Unfortunately the login engine is a bit simple at the moment for many applications. Also, without an agreed/enforced interface for these systems, I cannot make the plugin swappable if I want to change. Say I want to start with a light weight system, my site grows in features and I want to move to something a bit more iron clad, I have to put on the sugery gloves again. Sort of defeats the purpose of making a plugin, if similar systems can''t "Plug In" to your app. Well I''m sorry if I''ve offended anyone with my whinge... As I said, there are nifty aspects to all these systems as they are. It''s just at the moment, for me, it''s a case of "Which one will win" and become the standard (Not talking about in the core). I don''t really like this idea. I''d rather every system live together in peace and fill their niches, but I don''t see how that can happen without some kind of common interface used for the simple things and each one becoming a plugin/engine. Cheers Dan On 11/11/05, Dibya Prakash <prakash.dibya-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Hi Peter and Jake, > I am implementing a similar scenario on one of the projects I am working > on. > I am also implementing the same concept of account groups. > Regards > Dibya Prakash > > On 11/10/05, Jake Janovetz <jake-LtUAOcpEmBFWk0Htik3J/w@public.gmane.org> wrote: > > > Hi Peter- > > I am implementing an authentication system in an app I''m working on, > > too. I started with the SaltedHashLoginGenerator as a start but then > > modified it for my purposes. I basically decided that any login generator > > would not be ideal for my purposes. Rather than working around it, I''d use > > it as a base. The biggest disadvantage to this approach is losing track of > > updates with the main core. > > Specifically, I have added AccountGroups which define priviledge > > classes. Each account, then belongs to exactly one AccountGroup. > > Jake > > > > ------------------------------ > > *From:* Peter Michaux [mailto:petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org] > > *Sent:* Thursday, November 10, 2005 12:00 AM > > *To:* rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > *Subject:* [Rails] Athentication > > > > Hi, > > > > Can someone point me in a direction where I can learn more about > > handling athentication in a Rails app? I''m thinking about having an > > administrator belonging to one or more admin groups. Each admin group having > > it''s own set of privilages that might overlap. > > > > Thanks, > > Peter > > > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On Nov 10, 2005, at 5:43 PM, Liquid wrote:> Is it just me or is the number and variation of the various login/ > security systems a bit disturbing. > > The debate on what system to use has been on this list for a long > time. So I thought I''d add my $0.02 as well ;) Before I do > though, my hat goes off to the guys who have written these. There > are some clever bits in all of them. > > I have been looking at all the different systems that I have been > able to find and they are all so different I am hesitant to > implement any of them. I''m no security expert so I don''t really > feal comfortable coding my own in case I miss something stupid. > The ones that I have tried are > > Login Generator - GENERATOR > Salted hash login generator - GENERATOR > Model Security - GENERATOR > Active RBAC - COMPONENT > Login Engine - ENGINE/PLUGIN > > These are either too complicated for my purposes, too simple, or > just plain un-updateable. I''ve read on the list that this is the > case for many people who, in the end write their own. >I''m not sure why you find it disturbing that there are several authentication options, especially when you have noticed that they vary in purpose and complexity. Look, I agree with you that it would be nice if there were *one* that fit the bill for most users. That''s why I''d encourage you to *help* with a project like ActiveRBAC or login engine. Also, keep in mind that these were written at various points in RoR''s evolution. Plugins were not available at the time any of these authentication systems were started, with the exception of the login engine.> This concerns me that there are so many out there with no common > interface for the simple everyday (almost every app) tasks like > setting filters and handling the login function, roles etc that it > forces people to roll their own, taking these apps further away > from any kind of standard in this area. Not very DRY. If I write > an app around one system, and then decide to use another, I will > most likely have to perform major surgery on my code. >Well, the ActiveRBAC project is really trying to make a standardized Rails authentication system that everyone can use. It grew out of the request from lots of people for roles based permissions, and I think it is clearly an effort to supply code that helps people stick with the DRY principle. Download it. Test it. Report bugs. Suggest improvements. Write some code and submit patches for the bugs.> In addition to the fact that these login systems do no play > nicely, is that most are geneators. Once I generate it, I almost > certainly need to tailor it for my app, but when I do this, it''s no > longer updateable. This has really made me look elsewhere above > all other problems. If there is a security flaw identified in one > of these systems after implementation, then how the hell, short of > re-writing it do I fix it? (as I said, I''m not a security expert) >Yes, it''s hard to update generated code. But it''s not impossible, and there have been suggestions on the Wiki about how to isolate your code from the generated code. In fact, I did this in one of my own uses of the SHLG and it was actually fairly easy to upgrade. The only things I generally had to fix were the view templates and the configuration file.> The configuration setup for ActiveRBAC is very complicated and I > have to mash the download (I''m on windows so no links) every > different app I want to put it into. > > I like the idea of the engine/plugin. I can extend the model and > controllers to suit my app without upsetting the base install, and > I can also update it whenever I need/want to. Unfortunately the > login engine is a bit simple at the moment for many applications. > Also, without an agreed/enforced interface for these systems, I > cannot make the plugin swappable if I want to change. Say I want > to start with a light weight system, my site grows in features and > I want to move to something a bit more iron clad, I have to put on > the sugery gloves again. Sort of defeats the purpose of making a > plugin, if similar systems can''t "Plug In" to your app. >Not really. It can be a plugin simply for the purpose of separating the library from its user, in order to make upgrading the library easy.> Well I''m sorry if I''ve offended anyone with my whinge... As I > said, there are nifty aspects to all these systems as they are. > It''s just at the moment, for me, it''s a case of "Which one will > win" and become the standard (Not talking about in the core). I > don''t really like this idea. I''d rather every system live together > in peace and fill their niches, but I don''t see how that can happen > without some kind of common interface used for the simple things > and each one becoming a plugin/engine.It''s fine to whine about the generators. I can take it :) However, this subject comes up again and again on the list. People are upset that there isn''t a standard authentication system. But the fact of the matter is, a core or plugin authentication system is not going to pop into existence overnight just because people ask for it. As it stands, most of these systems have been donated by people doing the work in their spare time. It is going to require everyone who has a vested interest in seeing a common one available to help out if you want one that is going to have all the features and simplicity in system integration that you ask for. So, I would encourage you to get involved with ActiveRBAC or login engine projects.> > Cheers > Dan > > On 11/11/05, Dibya Prakash <prakash.dibya-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > Hi Peter and Jake, > > I am implementing a similar scenario on one of the projects I am > working on. > > I am also implementing the same concept of account groups. > > Regards > Dibya Prakash > > > On 11/10/05, Jake Janovetz < jake-LtUAOcpEmBFWk0Htik3J/w@public.gmane.org> wrote: > Hi Peter- > > I am implementing an authentication system in an app I''m working > on, too. I started with the SaltedHashLoginGenerator as a start > but then modified it for my purposes. I basically decided that any > login generator would not be ideal for my purposes. Rather than > working around it, I''d use it as a base. The biggest disadvantage > to this approach is losing track of updates with the main core. > > Specifically, I have added AccountGroups which define priviledge > classes. Each account, then belongs to exactly one AccountGroup. > > Jake > > > From: Peter Michaux [mailto:petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org] > Sent: Thursday, November 10, 2005 12:00 AM > To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > Subject: [Rails] Athentication > > > Hi, > > Can someone point me in a direction where I can learn more about > handling athentication in a Rails app? I''m thinking about having an > administrator belonging to one or more admin groups. Each admin > group having it''s own set of privilages that might overlap. > > Thanks, > Peter > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails
My £0.02 (not intentionally of greater value than $0.02 - that''s just economics + geography! ;-) ) -- I would LOVE (let me reiterate that in capital letters again - LOVE) people to contribute to the login engine. It''s missing features, certainly, and there are always bugs appearing in it too: one of my main motivations for making engines public was the hope that it would enable people to extend and fix it in a much more transparent way that generators allow. If you feel that the login engine isn''t enough for you, it''s quite easily extendable. I hope to soon be in the position of releasing the ''user engine'' (name subject to change), which builds roles and permissions on top of the existing login engine whilst reusing as much of that existing code as possible. So that should provide a means for people to ''upgrade'' their user control without too much hassle. I hope that once that gets thrown out to the wolves that people will tear it apart, test it to death and if I''m very very lucky, submit patches and work together to improve it and make it more robust. Please do get involved in these projects, whichever you feel is most worthy or best suits your particular development needs/style -- the Rails community can only benefit from having more developers examining and working on these extremely common and useful application components. On 11/10/05, Joseph Hosteny <jhosteny-ee4meeAH724@public.gmane.org> wrote:> > On Nov 10, 2005, at 5:43 PM, Liquid wrote: > > > Is it just me or is the number and variation of the various login/ > > security systems a bit disturbing. > > > > The debate on what system to use has been on this list for a long > > time. So I thought I''d add my $0.02 as well ;) Before I do > > though, my hat goes off to the guys who have written these. There > > are some clever bits in all of them. > > > > I have been looking at all the different systems that I have been > > able to find and they are all so different I am hesitant to > > implement any of them. I''m no security expert so I don''t really > > feal comfortable coding my own in case I miss something stupid. > > The ones that I have tried are > > > > Login Generator - GENERATOR > > Salted hash login generator - GENERATOR > > Model Security - GENERATOR > > Active RBAC - COMPONENT > > Login Engine - ENGINE/PLUGIN > > > > These are either too complicated for my purposes, too simple, or > > just plain un-updateable. I''ve read on the list that this is the > > case for many people who, in the end write their own. > > > > I''m not sure why you find it disturbing that there are several > authentication options, especially when you have noticed that they > vary in purpose and complexity. Look, I agree with you that it would > be nice if there were *one* that fit the bill for most users. That''s > why I''d encourage you to *help* with a project like ActiveRBAC or > login engine. > > Also, keep in mind that these were written at various points in RoR''s > evolution. Plugins were not available at the time any of these > authentication systems were started, with the exception of the login > engine. > > > This concerns me that there are so many out there with no common > > interface for the simple everyday (almost every app) tasks like > > setting filters and handling the login function, roles etc that it > > forces people to roll their own, taking these apps further away > > from any kind of standard in this area. Not very DRY. If I write > > an app around one system, and then decide to use another, I will > > most likely have to perform major surgery on my code. > > > > Well, the ActiveRBAC project is really trying to make a standardized > Rails authentication system that everyone can use. It grew out of the > request from lots of people for roles based permissions, and I think > it is clearly an effort to supply code that helps people stick with > the DRY principle. Download it. Test it. Report bugs. Suggest > improvements. Write some code and submit patches for the bugs. > > > In addition to the fact that these login systems do no play > > nicely, is that most are geneators. Once I generate it, I almost > > certainly need to tailor it for my app, but when I do this, it''s no > > longer updateable. This has really made me look elsewhere above > > all other problems. If there is a security flaw identified in one > > of these systems after implementation, then how the hell, short of > > re-writing it do I fix it? (as I said, I''m not a security expert) > > > > Yes, it''s hard to update generated code. But it''s not impossible, and > there have been suggestions on the Wiki about how to isolate your > code from the generated code. In fact, I did this in one of my own > uses of the SHLG and it was actually fairly easy to upgrade. The only > things I generally had to fix were the view templates and the > configuration file. > > > The configuration setup for ActiveRBAC is very complicated and I > > have to mash the download (I''m on windows so no links) every > > different app I want to put it into. > > > > I like the idea of the engine/plugin. I can extend the model and > > controllers to suit my app without upsetting the base install, and > > I can also update it whenever I need/want to. Unfortunately the > > login engine is a bit simple at the moment for many applications. > > Also, without an agreed/enforced interface for these systems, I > > cannot make the plugin swappable if I want to change. Say I want > > to start with a light weight system, my site grows in features and > > I want to move to something a bit more iron clad, I have to put on > > the sugery gloves again. Sort of defeats the purpose of making a > > plugin, if similar systems can''t "Plug In" to your app. > > > > Not really. It can be a plugin simply for the purpose of separating > the library from its user, in order to make upgrading the library easy. > > > Well I''m sorry if I''ve offended anyone with my whinge... As I > > said, there are nifty aspects to all these systems as they are. > > It''s just at the moment, for me, it''s a case of "Which one will > > win" and become the standard (Not talking about in the core). I > > don''t really like this idea. I''d rather every system live together > > in peace and fill their niches, but I don''t see how that can happen > > without some kind of common interface used for the simple things > > and each one becoming a plugin/engine. > > It''s fine to whine about the generators. I can take it :) > > However, this subject comes up again and again on the list. People > are upset that there isn''t a standard authentication system. But the > fact of the matter is, a core or plugin authentication system is not > going to pop into existence overnight just because people ask for it. > As it stands, most of these systems have been donated by people doing > the work in their spare time. It is going to require everyone who has > a vested interest in seeing a common one available to help out if you > want one that is going to have all the features and simplicity in > system integration that you ask for. > > So, I would encourage you to get involved with ActiveRBAC or login > engine projects. > > > > > Cheers > > Dan > > > > On 11/11/05, Dibya Prakash <prakash.dibya-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > Hi Peter and Jake, > > > > I am implementing a similar scenario on one of the projects I am > > working on. > > > > I am also implementing the same concept of account groups. > > > > Regards > > Dibya Prakash > > > > > > On 11/10/05, Jake Janovetz < jake-LtUAOcpEmBFWk0Htik3J/w@public.gmane.org> wrote: > > Hi Peter- > > > > I am implementing an authentication system in an app I''m working > > on, too. I started with the SaltedHashLoginGenerator as a start > > but then modified it for my purposes. I basically decided that any > > login generator would not be ideal for my purposes. Rather than > > working around it, I''d use it as a base. The biggest disadvantage > > to this approach is losing track of updates with the main core. > > > > Specifically, I have added AccountGroups which define priviledge > > classes. Each account, then belongs to exactly one AccountGroup. > > > > Jake > > > > > > From: Peter Michaux [mailto:petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org] > > Sent: Thursday, November 10, 2005 12:00 AM > > To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > Subject: [Rails] Athentication > > > > > > Hi, > > > > Can someone point me in a direction where I can learn more about > > handling athentication in a Rails app? I''m thinking about having an > > administrator belonging to one or more admin groups. Each admin > > group having it''s own set of privilages that might overlap. > > > > Thanks, > > Peter > > > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > > > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On 11/11/05, James Adam <james.adam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > My £0.02 (not intentionally of greater value than $0.02 - that''s just > economics + geography! ;-) ) -- > > I would LOVE (let me reiterate that in capital letters again - LOVE) > people to contribute to the login engine. It''s missing features, > certainly, and there are always bugs appearing in it too: one of my > main motivations for making engines public was the hope that it would > enable people to extend and fix it in a much more transparent way that > generators allow. > > If you feel that the login engine isn''t enough for you, it''s quite > easily extendable. I hope to soon be in the position of releasing the > ''user engine'' (name subject to change), which builds roles and > permissions on top of the existing login engine whilst reusing as much > of that existing code as possible. So that should provide a means for > people to ''upgrade'' their user control without too much hassle. I hope > that once that gets thrown out to the wolves that people will tear it > apart, test it to death and if I''m very very lucky, submit patches and > work together to improve it and make it more robust. > > Please do get involved in these projects, whichever you feel is most > worthy or best suits your particular development needs/style -- the > Rails community can only benefit from having more developers examining > and working on these extremely common and useful application > components.James, It''s not that I don''t feel that any of these projects aren''t worthy... far from it, I think they all have merit and lots of it, It''s just that I''m very frustrated at which one to use. I''m more than happy to contribute in any way that I can... It''s just that I''m not sure, at my skill level how I can do that. On 11/10/05, Joseph Hosteny <jhosteny-ee4meeAH724@public.gmane.org> wrote:> > > > On Nov 10, 2005, at 5:43 PM, Liquid wrote: > > > > > Is it just me or is the number and variation of the various login/ > > > security systems a bit disturbing. > > > > > > The debate on what system to use has been on this list for a long > > > time. So I thought I''d add my $0.02 as well ;) Before I do > > > though, my hat goes off to the guys who have written these. There > > > are some clever bits in all of them. > > > > > > I have been looking at all the different systems that I have been > > > able to find and they are all so different I am hesitant to > > > implement any of them. I''m no security expert so I don''t really > > > feal comfortable coding my own in case I miss something stupid. > > > The ones that I have tried are > > > > > > Login Generator - GENERATOR > > > Salted hash login generator - GENERATOR > > > Model Security - GENERATOR > > > Active RBAC - COMPONENT > > > Login Engine - ENGINE/PLUGIN > > > > > > These are either too complicated for my purposes, too simple, or > > > just plain un-updateable. I''ve read on the list that this is the > > > case for many people who, in the end write their own. > > > > > > > I''m not sure why you find it disturbing that there are several > > authentication options, especially when you have noticed that they > > vary in purpose and complexity. Look, I agree with you that it would > > be nice if there were *one* that fit the bill for most users. That''s > > why I''d encourage you to *help* with a project like ActiveRBAC or > > login engine. > > > > Also, keep in mind that these were written at various points in RoR''s > > evolution. Plugins were not available at the time any of these > > authentication systems were started, with the exception of the login > > engine. > > > > > This concerns me that there are so many out there with no common > > > interface for the simple everyday (almost every app) tasks like > > > setting filters and handling the login function, roles etc that it > > > forces people to roll their own, taking these apps further away > > > from any kind of standard in this area. Not very DRY. If I write > > > an app around one system, and then decide to use another, I will > > > most likely have to perform major surgery on my code. > > > > > > > Well, the ActiveRBAC project is really trying to make a standardized > > Rails authentication system that everyone can use. It grew out of the > > request from lots of people for roles based permissions, and I think > > it is clearly an effort to supply code that helps people stick with > > the DRY principle. Download it. Test it. Report bugs. Suggest > > improvements. Write some code and submit patches for the bugs. > > > > > In addition to the fact that these login systems do no play > > > nicely, is that most are geneators. Once I generate it, I almost > > > certainly need to tailor it for my app, but when I do this, it''s no > > > longer updateable. This has really made me look elsewhere above > > > all other problems. If there is a security flaw identified in one > > > of these systems after implementation, then how the hell, short of > > > re-writing it do I fix it? (as I said, I''m not a security expert) > > > > > > > Yes, it''s hard to update generated code. But it''s not impossible, and > > there have been suggestions on the Wiki about how to isolate your > > code from the generated code. In fact, I did this in one of my own > > uses of the SHLG and it was actually fairly easy to upgrade. The only > > things I generally had to fix were the view templates and the > > configuration file. > > > > > The configuration setup for ActiveRBAC is very complicated and I > > > have to mash the download (I''m on windows so no links) every > > > different app I want to put it into. > > > > > > I like the idea of the engine/plugin. I can extend the model and > > > controllers to suit my app without upsetting the base install, and > > > I can also update it whenever I need/want to. Unfortunately the > > > login engine is a bit simple at the moment for many applications. > > > Also, without an agreed/enforced interface for these systems, I > > > cannot make the plugin swappable if I want to change. Say I want > > > to start with a light weight system, my site grows in features and > > > I want to move to something a bit more iron clad, I have to put on > > > the sugery gloves again. Sort of defeats the purpose of making a > > > plugin, if similar systems can''t "Plug In" to your app. > > > > > > > Not really. It can be a plugin simply for the purpose of separating > > the library from its user, in order to make upgrading the library easy. > > > > > Well I''m sorry if I''ve offended anyone with my whinge... As I > > > said, there are nifty aspects to all these systems as they are. > > > It''s just at the moment, for me, it''s a case of "Which one will > > > win" and become the standard (Not talking about in the core). I > > > don''t really like this idea. I''d rather every system live together > > > in peace and fill their niches, but I don''t see how that can happen > > > without some kind of common interface used for the simple things > > > and each one becoming a plugin/engine. > > > > It''s fine to whine about the generators. I can take it :) > > > > However, this subject comes up again and again on the list. People > > are upset that there isn''t a standard authentication system. But the > > fact of the matter is, a core or plugin authentication system is not > > going to pop into existence overnight just because people ask for it. > > As it stands, most of these systems have been donated by people doing > > the work in their spare time. It is going to require everyone who has > > a vested interest in seeing a common one available to help out if you > > want one that is going to have all the features and simplicity in > > system integration that you ask for. > > > > So, I would encourage you to get involved with ActiveRBAC or login > > engine projects. > > > > > > > > Cheers > > > Dan > > > > > > On 11/11/05, Dibya Prakash <prakash.dibya-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > Hi Peter and Jake, > > > > > > I am implementing a similar scenario on one of the projects I am > > > working on. > > > > > > I am also implementing the same concept of account groups. > > > > > > Regards > > > Dibya Prakash > > > > > > > > > On 11/10/05, Jake Janovetz < jake-LtUAOcpEmBFWk0Htik3J/w@public.gmane.org> wrote: > > > Hi Peter- > > > > > > I am implementing an authentication system in an app I''m working > > > on, too. I started with the SaltedHashLoginGenerator as a start > > > but then modified it for my purposes. I basically decided that any > > > login generator would not be ideal for my purposes. Rather than > > > working around it, I''d use it as a base. The biggest disadvantage > > > to this approach is losing track of updates with the main core. > > > > > > Specifically, I have added AccountGroups which define priviledge > > > classes. Each account, then belongs to exactly one AccountGroup. > > > > > > Jake > > > > > > > > > From: Peter Michaux [mailto:petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org] > > > Sent: Thursday, November 10, 2005 12:00 AM > > > To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > > Subject: [Rails] Athentication > > > > > > > > > Hi, > > > > > > Can someone point me in a direction where I can learn more about > > > handling athentication in a Rails app? I''m thinking about having an > > > administrator belonging to one or more admin groups. Each admin > > > group having it''s own set of privilages that might overlap. > > > > > > Thanks, > > > Peter > > > > > > _______________________________________________ > > > Rails mailing list > > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > > > > > > > > > _______________________________________________ > > > Rails mailing list > > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > > > > > > _______________________________________________ > > > Rails mailing list > > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On Thu, Nov 10, 2005 at 11:49:23PM +0000, James Adam wrote:> I would LOVE (let me reiterate that in capital letters again - LOVE) > people to contribute to the login engine. It''s missing features, > certainly, and there are always bugs appearing in it too: one of my > main motivations for making engines public was the hope that it would > enable people to extend and fix it in a much more transparent way that > generators allow.Well, that''s good news for me. :) http://keegan.thebasement.org/articles/2005/11/09/logging-in-with-rails> If you feel that the login engine isn''t enough for you, it''s quite > easily extendable. I hope to soon be in the position of releasing the > ''user engine'' (name subject to change), which builds roles and > permissions on top of the existing login engine whilst reusing as much > of that existing code as possible. So that should provide a means for > people to ''upgrade'' their user control without too much hassle. I hope > that once that gets thrown out to the wolves that people will tear it > apart, test it to death and if I''m very very lucky, submit patches and > work together to improve it and make it more robust.I need roles functionality ASAP, and was planning on integrating that with the LoginEngine, as noted in the post above. Glad to hear you''re working on this. The sooner the release, the better... Another problem that has been on my mind regarding this topic is the need for a user administration system. If you think UserEngine (RoleEngine?) should be seperate from LoginEngine, perhaps something like AdminEngine should also be a different engine? Thanks! -- Keegan Quinn <keegan-g9krTqASs3z/gVISOhv/wg@public.gmane.org> CEO, Producer the basement productions http://www.thebasement.org _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On 11/11/05, Keegan Quinn <keegan-g9krTqASs3z/gVISOhv/wg@public.gmane.org> wrote:> http://keegan.thebasement.org/articles/2005/11/09/logging-in-with-railsIf you have notes about problems, can you write them up and either email them to me or create Tickets on the Trac page? :)> I need roles functionality ASAP, and was planning on integrating that > with the LoginEngine, as noted in the post above. Glad to hear you''re > working on this. The sooner the release, the better...It will be next week before what I''ve done sees the light of day, and you''re not going to be amazed by it. That said, I''m happy to throw it out there for people to criticise it to death. Perhaps at least then people might see one way of ''layering'' engines that isn''t the nightmare that certain luminaries fear it to be.> Another problem that has been on my mind regarding this topic is the need > for a user administration system. If you think UserEngine (RoleEngine?) > should be seperate from LoginEngine, perhaps something like AdminEngine > should also be a different engine?The only reason that the ''UserEngine'' doesn''t completely subsume the LoginEngine is because it would be a waste of development effort to fix bugs in the common code between them. I''m not sure how this would play out between what in your mind is distinct between the role additions, and an administration interface. What do you think you should have in an administration interface? There''s a bit of a storm in engines-land at the moment, but hopefully we''ll see some good stuff come out of it that benefits everyone. In the meantime, please keep me updated about your thoughts and progress - great post on your blog! - james