in reply to Different Database Permissions Using Class::DBI

First of all, yes, I think you're being too paranoid. You don't let end users run arbitrary code against these classes, do you? So who cares what they allow? In a persistent environment where database connections are kept open, multiple database logins can be a real problem because they tie up more resources.

As for how to do it, it's pretty simple. That whole base class setup is just a suggestion. You can either not have one at all and decide which database login to use in your class based on some config thing, or you could make Person a base class and then subclass it with MutablePerson and ImmutablePerson, moving the set_db call down to these subclasses.

  • Comment on Re: Different Database Permissions Using Class::DBI

Replies are listed 'Best First'.
Re: Re: Different Database Permissions Using Class::DBI
by Anonymous Monk on Jul 02, 2003 at 20:41 UTC
    Uh, you typically restrict your DB to do certain things 'cause you don't want people doing those things. That's why a lot of companies don't allow anything but stored proc's from beign run. You can't run arbitrary sql.

    Some that do allow sql, don't usually allow deletes, since you don't want an arbitrary "delete from blah".

    It's not paranoia.. it's good security. Or do you not believe in firewalls too.

[reply]
      You don't understand. We're not talking about running arbitrary SQL here, just executing pre-defined method calls on a class. Security is typically enforced either in these method calls (i.e. do you have permission to call this method) or at an even higher level in the web interface. A person who isn't allowed to delete something from the database would simply not be presented with a delete option in the web UI. This makes the extra work to use different database logins redundant, so most web apps do not use multiple database logins for security.
[reply]

In Section Seekers of Perl Wisdom