You are right and performance is something that I also concern about. Not sure if it the second level cache would help in that scenario? otherwise I have to fall back to your suggestion "GenerateOperatons".
On Mar 27, 3:10 am, Bart Reyserhove <[email protected]> wrote: > That's a different story of course. Instead of generating them on the fly. > Can't you have an action method: "GenerateOperations" or something like > that? > Generating them in a filter will have performance issues I think. > > On Thu, Mar 26, 2009 at 2:27 PM, c.sokun <[email protected]> wrote: > > > The reason for step 1 & 2 is to populate Operations list on the fly so > > I don't have to develop UI for Rhino-Security's Operation CRUD. > > I would only take care admin UI for assigning operation permission to > > User/UsersGroup. > > > That how I though is it not practical if I go that route? > > > On Mar 26, 4:30 pm, Bart Reyserhove <[email protected]> wrote: > > > I do not understand why you need step 1 and 2. Here is what we do in our > > > filter: > > > > 1. Check whether user is authenticated > > > 2. If yes: get the operation based on the controller type and > > actionname > > > (string.Format("/{0}/{1}", > > filterContext.Controller.GetType().BaseType.Name, > > > actionName)) > > > 3. Check whether the logged in user is allowed to perform the > > operation. > > > > This works very nice. > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en -~----------~----~----~----~------~----~------~--~---
