On Nov 14, 2005, at 4:09 AM, Alex Y. wrote:
Toby B. wrote:
Alex - you have a good idea there for, as you say, yes and no
auth systems, and the approach (separate apps) has been advocated
as a way to separate roles for destructive data handling when
building Rails apps.
That’s not quite what I’m suggesting, although you could certainly
use my suggestion with that.
Oh, I know – I was bringing up a related topic, which is creating
admin applications to run parallel to user applications.
I think we’re talking about the same thing here. I’m not
suggesting two separate front-end apps, one with full CRUD
privileges and one with read-only rights, but rather, like you say,
a separate auth app which can be queried by the front-end app when
it runs across a protected section.
I know what you’re saying about a centralized auth app, but my point
was that, when taken to the extreme, separate rails applications
(whether visible to all users, some users or only to other apps)
isn’t – for me – a sufficient replacement for using restricted
accounts within a database.
Centralized auth is a good idea, but what about non-password data?
Running every select with a full CRUD user means that if those user
credentials are compromised, or if a select is somehow exploited, you
risk everything. Running selects as select-only users limits the
damage that can be done. The same applies for updates and deletes.
I think the approach you take to managing the auth connection
(service-oriented, or by modding AR) could be useful for me in
working out an elegant and somewhat railsy way of handling sets of db
user accounts.
Keep me posted 