On Wed, 2010-07-07 at 14:40 -0400, Dale Newfield wrote: > On 7/7/10 2:11 PM, Ken wrote: > > This is a hand rolled solution I used: > > Create an interceptor which checks if a User object exists when > > accessing a secure package, if it does not exist redirect the user to a > > login page and record the initial url (will redirect back to that page > > after login). > > This isn't part 2 of the asked question, but part 1. "Best Practices" > in security usually means "Don't roll your own" since you're very likely > to implement the same bugs that widely used packages have had time and > eyeballs needed to fix. > > > I use hibernate... so the user object contains a connection to the > > database. > > For the duration of the hibernate session, yes. But be careful about > this, too, as for example if you store that in the http session you may > be keeping hibernate sessions open far too long, or encountering > hibernate backed objects that no longer have their active session and > thus their connection to the DB.
The application is internal and the user needs constant access to the database, for order entry and retrieval (among other things), I open a small connection pool per user and am not worried about it being closed down except once a day... even then I'm not very worried the server is a decent iSeries the user base is small relative to its potential... The application is supposed to fill the purpose of a "green screen" connection (5250 session). > > > If you're also using hibernate you'll > > notice you can supply the specific "hibernate.cfg.xml" when establishing > > the connection, by making this choice dependant on the particular user > > you can supply different database connections or even restrict data > > access. In this case I think xml files are better than annotations as > > you don't need to change the POJO which the *.hbm.xml files refer to. > > That's an interesting idea, although I don't know how having a per-user > hibernate.cfg allows you to control which rows of which tables are > fetchable...and I'd think complex business logic would quickly make this > untenable. I suppose it might, my system is pretty basic. But one possibility is using named queries... (of course everyone thinks _their_ solution is the easiest until they see something better, I'm always shopping!). Because the hibernate.cfg is the base for bringing in the rest of the associated xml files, simply create a hibernate.cfg per role (I'm assuming something obviously about the tractability for the number of roles but in my case there's only three, right now)... Then have your particular hibernate.cfg.xml bring in a roll specific namedQuery.hbm.xml file and vola... you can do some fancy footwork. Since you can control updates via the named queries. I'm not certain about this idea but, if the application has complex state which needs to be taken into account... as perhaps the OP was alluding too... well perhaps hibernate should also be made aware of it, persist their state (the business objects state) to an in in memory database (or the production DB, if you're lucky enough to be the DBA and running on the same system...) then the queries can take that into account, which aught to be way easier that trying to maintain some crazy state machine combined with data access. In this way decisions can be pushed down into the data layer, everything becomes a query. Which makes sense, someone is asking a question of the data. > "Person X has read access to all rows of Y that are not marked > 'private', and write access to all rows of Y that are linked to some > other object that lists person X as a manager." > > -Dale
