One way is to create admin''s part within project''s folder using namespaces so that admin controllers are stored in app/controllers/ admin/ and restrict access to these controllers for mere mortals using authentication. It means that both users and admins work with the same database, they share the same models, only the controllers are different. The other way is to create another project totally dedicated to administration of the first, main project. So that models, controllers, logs, libraries (all that stuff) for admin''s project and the main project are stored in different folders (locally on the server). Admins have an access to the same models user have. Admins have an access to the database of the main project (which could be done in rails). Yet users don''t have an access to admin''s database (and even more so for controllers), since these are different databases, unlike the first way to implement this. I slightly tend to implement it the second way. For security purposes. Namely, mere users and admins don''t share databases. Of course, admins need to authorize themselves to gain control to administration anyway, but, obviously, it''s secure, when the databases are separated from each other. However, I believe, as always, both methods have their advantages and disadvantages. Yet I cannot foresee disadvantages of the second way, since this is the first time ever I''m trying to implement administration. Which is the best way in your opinion? And what are the pros and cons of both ways? Thanks. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Dec 16, 2007, at 10:21 AM, truetype wrote:> One way is to create admin''s part within project''s folder using > namespaces so that admin controllers are stored in app/controllers/ > admin/ and restrict access to these controllers for mere mortals using > authentication. It means that both users and admins work with the same > database, they share the same models, only the controllers are > different. > > The other way is to create another project totally dedicated to > administration of the first, main project. So that models, > controllers, logs, libraries (all that stuff) for admin''s project and > the main project are stored in different folders (locally on the > server). Admins have an access to the same models user have. Admins > have an access to the database of the main project (which could be > done in rails). Yet users don''t have an access to admin''s database > (and even more so for controllers), since these are different > databases, unlike the first way to implement this. > > I slightly tend to implement it the second way. For security purposes. > Namely, mere users and admins don''t share databases. Of course, admins > need to authorize themselves to gain control to administration anyway, > but, obviously, it''s secure, when the databases are separated from > each other. > > However, I believe, as always, both methods have their advantages and > disadvantages. Yet I cannot foresee disadvantages of the second way, > since this is the first time ever I''m trying to implement > administration. > > Which is the best way in your opinion? And what are the pros and cons > of both ways?I do both depending on the application. When Admin functionality closely follows application functionality and is generally limited to CRUD and simplistic approval process functions, then I just build admin inline with the application. However, when admin functionality starts to look like a completely different application because of the way data must be combined for review, reports, business logic more complex than simple approvals, and especially when the UI demands go beyond simple list & record views, then I build a separate application because at that point it really is a separate application due to differing UI, organization, logic, etc. IMO there''s no real security advantage to either structure. -- def gw acts_as_n00b writes_at(www.railsdev.ws) end --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Thanks for your answer. How about deployment? I''ve never deployed ror application to date, so the deployment itself could become an experience for me, let alone simultaneous deployment of two applications. Is there any difference or do any challenges arise, when you deploy application and its admin part? Thanks. On Dec 16, 10:35 pm, Greg Willits <li...-0Bv1hcaDFPRk211Z5VL+QA@public.gmane.org> wrote:> On Dec 16, 2007, at 10:21 AM, truetype wrote: > > > > > One way is to create admin''s part within project''s folder using > > namespaces so that admin controllers are stored in app/controllers/ > > admin/ and restrict access to these controllers for mere mortals using > > authentication. It means that both users and admins work with the same > > database, they share the same models, only the controllers are > > different. > > > The other way is to create another project totally dedicated to > > administration of the first, main project. So that models, > > controllers, logs, libraries (all that stuff) for admin''s project and > > the main project are stored in different folders (locally on the > > server). Admins have an access to the same models user have. Admins > > have an access to the database of the main project (which could be > > done in rails). Yet users don''t have an access to admin''s database > > (and even more so for controllers), since these are different > > databases, unlike the first way to implement this. > > > I slightly tend to implement it the second way. For security purposes. > > Namely, mere users and admins don''t share databases. Of course, admins > > need to authorize themselves to gain control to administration anyway, > > but, obviously, it''s secure, when the databases are separated from > > each other. > > > However, I believe, as always, both methods have their advantages and > > disadvantages. Yet I cannot foresee disadvantages of the second way, > > since this is the first time ever I''m trying to implement > > administration. > > > Which is the best way in your opinion? And what are the pros and cons > > of both ways? > > I do both depending on the application. When Admin functionality > closely follows application functionality and is generally limited to > CRUD and simplistic approval process functions, then I just build > admin inline with the application. > > However, when admin functionality starts to look like a completely > different application because of the way data must be combined for > review, reports, business logic more complex than simple approvals, > and especially when the UI demands go beyond simple list & record > views, then I build a separate application because at that point it > really is a separate application due to differing UI, organization, > logic, etc. > > IMO there''s no real security advantage to either structure. > > -- > def gw > acts_as_n00b > writes_at(www.railsdev.ws) > end--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
If you had two different applications, why would you have two different databases? It seems like it would be a mess because you would have to specify the connection type for some of the models. Wouldn''t it make sense just to use the same database and models, and just have separate everything else? You could synchronize the Models folder using source control, so you wouldn''t have to repeat any of that functionality across the two apps. You would then need to specify all the routes, but you''re doing that anyways, because you''re using resources, right? ;) On Dec 16, 12:03 pm, truetype <oleg.lya...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Thanks for your answer. > > How about deployment? I''ve never deployed rorapplicationto date, so > the deployment itself could become an experience for me, let alone > simultaneous deployment of two applications. Is there any difference > or do any challenges arise, when you deployapplicationand its admin > part? > > Thanks. > > On Dec 16, 10:35 pm, Greg Willits <li...-0Bv1hcaDFPRk211Z5VL+QA@public.gmane.org> wrote: > > > On Dec 16, 2007, at 10:21 AM, truetype wrote: > > > > One way is to create admin''s part within project''s folder using > > > namespaces so that admin controllers are stored in app/controllers/ > > > admin/ and restrict access to these controllers for mere mortals using > > > authentication. It means that both users and admins work with the same > > > database, they share the same models, only the controllers are > > > different. > > > > The other way is to create another project totally dedicated to > > > administration of the first, main project. So that models, > > > controllers, logs, libraries (all that stuff) for admin''s project and > > > the main project are stored in different folders (locally on the > > > server). Admins have an access to the same models user have. Admins > > > have an access to the database of the main project (which could be > > > done in rails). Yet users don''t have an access to admin''s database > > > (and even more so for controllers), since these are different > > > databases, unlike the first way to implement this. > > > > I slightly tend to implement it the second way. For security purposes. > > > Namely, mere users and admins don''t share databases. Of course, admins > > > need to authorize themselves to gain control to administration anyway, > > > but, obviously, it''s secure, when the databases are separated from > > > each other. > > > > However, I believe, as always, both methods have their advantages and > > > disadvantages. Yet I cannot foresee disadvantages of the second way, > > > since this is the first time ever I''m trying to implement > > > administration. > > > > Which is the best way in your opinion? And what are the pros and cons > > > of both ways? > > > I do both depending on theapplication. When Admin functionality > > closely followsapplicationfunctionality and is generally limited to > > CRUD and simplistic approval process functions, then I just build > > admin inline with theapplication. > > > However, when admin functionality starts to look like a completely > > differentapplicationbecause of the way data must be combined for > > review, reports, business logic more complex than simple approvals, > > and especially when the UI demands go beyond simple list & record > > views, then I build a separateapplicationbecause at that point it > > really is a separateapplicationdue to differing UI, organization, > > logic, etc. > > > IMO there''s no real security advantage to either structure. > > > -- > > def gw > > acts_as_n00b > > writes_at(www.railsdev.ws) > > end--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---