Re: role-based access to pages and parts of pages - ideas?
You have role in auth-fw and you could authorize various parts of the webapp according to the role but you're not able to filter pages Le Mardi 13 Janvier 2004 12:59, Stefan Klein a écrit : > Alex, > > >It would be great if you could. We can also bring > >this up with the developers to see what they think > > I am happy to help, if someone gives my a quick breakdown on how the > authorization-fw works. I am quite short of time at the moment and I > can't run through the code/documentation myself. From what I've gathered > so far you have to get hold of the Handler or the HandlerManager or > something and then ask it to authorize. Details, anyone? > > Also, I don't think the authorization framework uses various roles per > user, does it? So the transformer could only filter based on the user > (but that might be good enough in many cases) > > Stefan > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: role-based access to pages and parts of pages - ideas?
Alex, >It would be great if you could. We can also bring >this up with the developers to see what they think I am happy to help, if someone gives my a quick breakdown on how the authorization-fw works. I am quite short of time at the moment and I can't run through the code/documentation myself. From what I've gathered so far you have to get hold of the Handler or the HandlerManager or something and then ask it to authorize. Details, anyone? Also, I don't think the authorization framework uses various roles per user, does it? So the transformer could only filter based on the user (but that might be good enough in many cases) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: role-based access to pages and parts of pages - ideas?
Thanks a lot Stefan. I I'm looking at it Le Mardi 13 Janvier 2004 10:11, Stefan Klein a écrit : > Nicolas, > > > I'm interested: I've done the same work but with an XSL Stylesheet but > > a java class would be better. Where can we get it? > > I've sent you a copy of my classes off-list. It is, however, as I pointed > out before, tailored to my own little authentication system, not to > cocoon's framework. Since the transformer is very simple, it should be > very easy to adapt, though, given some knowledge of the cocoon framework > (which I don't have enough of). > > To make you understand the code, here's a quick outline of my system: > Just like cocoon's authorization handlers, it uses an Avalon component > Authorizer that does the actual checking of permissions of a user that is > logged in (I sent you this class to make you understand better). This > component is used by the transformer and by an AuthorizerAction. > User information is - again, just like in cocoon's framework - stored in > a session context. Creation of this context is done by an > AuthenticationAction that checks the identity of a user (again, I've > included the class). > > Hope you can make something out of it. Feel free to ask questions. > Stefan > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: role-based access to pages and parts of pages - ideas?
Nicolas, > I'm interested: I've done the same work but with an XSL Stylesheet but > a java class would be better. Where can we get it? I've sent you a copy of my classes off-list. It is, however, as I pointed out before, tailored to my own little authentication system, not to cocoon's framework. Since the transformer is very simple, it should be very easy to adapt, though, given some knowledge of the cocoon framework (which I don't have enough of). To make you understand the code, here's a quick outline of my system: Just like cocoon's authorization handlers, it uses an Avalon component Authorizer that does the actual checking of permissions of a user that is logged in (I sent you this class to make you understand better). This component is used by the transformer and by an AuthorizerAction. User information is - again, just like in cocoon's framework - stored in a session context. Creation of this context is done by an AuthenticationAction that checks the identity of a user (again, I've included the class). Hope you can make something out of it. Feel free to ask questions. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: role-based access to pages and parts of pages - ideas?
I'll have a look at the code too and see what I can contribute. This is too interesting to let it pass by. Bye, Helma > -Original Message- > From: Alex Romayev [mailto:[EMAIL PROTECTED] > Sent: Monday, 12 January 2004 17:37 > To: [EMAIL PROTECTED] > Subject: Re: role-based access to pages and parts of pages - ideas? > > > > --- Stefan Klein <[EMAIL PROTECTED]> wrote: > > Alex, > > > > > I really like Stefan's idea of authorization > > > transformer, which filters data based on your > > > permissions. > > Thanks. Good ideas in your mail, too. I think I'll > > rethink some of my > > sitemap. > > > > > Have you thought of contributing it to > > > the project? > > The project's approach to authorization is the > > authentication-framework > > which I don't understand to enough depth to > > integrate my transformer with > > it. > > However, if you're interested or if you think, you > > could make something > > worthwhile out of it, I am happy to send you the > > class. It's very short > > and simple, anyway. I took the inspiration from the > > FilterTransformer, > > but it's even simpler than that. > > It would be great if you could. We can also bring > this up with the developers to see what they think. > > > > > Stefan > > > > > - > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > = > Alex Romayev > Software Architect > http://www.romayev.com > [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: role-based access to pages and parts of pages - ideas?
--- Stefan Klein <[EMAIL PROTECTED]> wrote: > Alex, > > > I really like Stefan's idea of authorization > > transformer, which filters data based on your > > permissions. > Thanks. Good ideas in your mail, too. I think I'll > rethink some of my > sitemap. > > > Have you thought of contributing it to > > the project? > The project's approach to authorization is the > authentication-framework > which I don't understand to enough depth to > integrate my transformer with > it. > However, if you're interested or if you think, you > could make something > worthwhile out of it, I am happy to send you the > class. It's very short > and simple, anyway. I took the inspiration from the > FilterTransformer, > but it's even simpler than that. It would be great if you could. We can also bring this up with the developers to see what they think. > > Stefan > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > = Alex Romayev Software Architect http://www.romayev.com [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: role-based access to pages and parts of pages - ideas?
Hi, I'm interested: I've done the same work but with an XSL Stylesheet but a java class would be better. Where can we get it? Le Samedi 10 Janvier 2004 15:49, Stefan Klein a écrit : > Alex, > > > I really like Stefan's idea of authorization > > transformer, which filters data based on your > > permissions. > > Thanks. Good ideas in your mail, too. I think I'll rethink some of my > sitemap. > > > Have you thought of contributing it to > > the project? > > The project's approach to authorization is the authentication-framework > which I don't understand to enough depth to integrate my transformer with > it. > However, if you're interested or if you think, you could make something > worthwhile out of it, I am happy to send you the class. It's very short > and simple, anyway. I took the inspiration from the FilterTransformer, > but it's even simpler than that. > > Stefan > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: role-based access to pages and parts of pages - ideas?
Alex, > I really like Stefan's idea of authorization > transformer, which filters data based on your > permissions. Thanks. Good ideas in your mail, too. I think I'll rethink some of my sitemap. > Have you thought of contributing it to > the project? The project's approach to authorization is the authentication-framework which I don't understand to enough depth to integrate my transformer with it. However, if you're interested or if you think, you could make something worthwhile out of it, I am happy to send you the class. It's very short and simple, anyway. I took the inspiration from the FilterTransformer, but it's even simpler than that. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: role-based access to pages and parts of pages - ideas?
Helma, Here are a few ideas that I've used and I think you might benefit from them as well: I like to think that each page is assembled of portlets, e.g. navigation portlet, form portlets, information portlets, related links portlets, etc. The pages are internal (i.e. protected) and external. This is how I break up my sitemap based on this logic: 1. I match for internal pages and external pages (just like Stefan suggests), for example internal/* and protected/*. This should make your authentication matching easier. My page pipeline simply aggregates portlets and applies a layout stylesheet to place them within the page. 2. I have separate pipelines for portlets and what I call resources (see below). These pipelines are "internal", so I don't need to worry about security for them. 3. I have a separate pipeline for portlets, which matches on */*.portlet, i.e. /.portlet. Each portlet gets its input from a resource, which means that the responsibility of the portlet is to do the styling. I then subcategories portlets based on their presentation style: of which can access > the resource "patient record x". > Now the authorization goes like this: > user smith requests access to "patient record x". > The authorizer checks > which roles have access to "patient record x" and > then whether user smith > has any of these roles. So in our case smith could > be doctor or nurse and > would be granted access either way. > > The sitemap still looks the same, but instead of a > role you pass a > resource to the action. > > > 2. My sitemap is growing rapidly and by adding > enormous amounts of > > comment I'm trying to keep it clear, but I find it > more and more > > difficult to find what I'm looking for. So > configuring authorisation in > > the sitemap is not really my idea of keeping it > clear and separated. > > 3. I want a general way of handling several pages, > i.e. with a minimal > > number of pipelines. If in future I add a page, I > want it to be > > integrated without touching the sitemap. I was > thinking of adding > > access rules to the source of the form, but that > would also spread the > > authorization. :-( > > I agree with Alex, it might be useful to have a look > at your sitemap, if > we can. Authorization generally shouldn't add a lot > of overhead. > > What I do is use sub-sitemaps for protected areas. > So in my main sitemap > I have > > > > > > src="protected/sitemap.xmap" > check-reload="true"/> > > > > This way any request of form //host/protected/* > needs authorization. The > autorization is done based on the requested url (the > url after protected/ > is actually the authorization resource). So in our > example above the > request could be //host/protected/patient-record-x. > The authorizer than > checks (in my case against a database) if any of the > user's roles has > access to that resource. If so, the request is > passed on to the protected > sitemap. > Notice, that you will never have to change anything > about this to add new > pages to the protected sitemap. You only need to > make sure the user's > roles have access to the new resource (in my case, > by adding an entry in > the database). The protected sitemap stays clear of > authorization > functionality. > > > 4. One or more roles may have more > features/information on a page than > > others. This would mean I have to customize role > checking for every > > page item. :-( > For that I wrote a transformer. My pages contain > statements of the form > > > > On encountering a cms:auth tag the transformer > checks whether the user > has that role. If so, it passes on the enclosed > content. If not, it > filters it. > > HTH > Stefan > > > > > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > = Alex Romayev Software Architect http://www.romayev.com [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: role-based access to pages and parts of pages - ideas?
Helma, I'll tell you a little more about me approach (it was a rather rough summary I gave you). Maybe some of the problems you see are solved already. > 1. I have various roles (between 5 and 10) which overlap in access > authentication, so every pipeline would need to check for several roles > and if I need to add extra roles I need to revisit every pipeline. :-( I don't actually check for roles, but use resources as another level of abstraction: resources are what we want to protect (e.g. certain urls, combinations of urls and request-params, whatever) roles have access to resources users have roles E.g. you have a type of patient record that can be accessed by nurses and doctors. So you have roles "nurse" and "doctor" both of which can access the resource "patient record x". Now the authorization goes like this: user smith requests access to "patient record x". The authorizer checks which roles have access to "patient record x" and then whether user smith has any of these roles. So in our case smith could be doctor or nurse and would be granted access either way. The sitemap still looks the same, but instead of a role you pass a resource to the action. > 2. My sitemap is growing rapidly and by adding enormous amounts of > comment I'm trying to keep it clear, but I find it more and more > difficult to find what I'm looking for. So configuring authorisation in > the sitemap is not really my idea of keeping it clear and separated. > 3. I want a general way of handling several pages, i.e. with a minimal > number of pipelines. If in future I add a page, I want it to be > integrated without touching the sitemap. I was thinking of adding > access rules to the source of the form, but that would also spread the > authorization. :-( I agree with Alex, it might be useful to have a look at your sitemap, if we can. Authorization generally shouldn't add a lot of overhead. What I do is use sub-sitemaps for protected areas. So in my main sitemap I have This way any request of form //host/protected/* needs authorization. The autorization is done based on the requested url (the url after protected/ is actually the authorization resource). So in our example above the request could be //host/protected/patient-record-x. The authorizer than checks (in my case against a database) if any of the user's roles has access to that resource. If so, the request is passed on to the protected sitemap. Notice, that you will never have to change anything about this to add new pages to the protected sitemap. You only need to make sure the user's roles have access to the new resource (in my case, by adding an entry in the database). The protected sitemap stays clear of authorization functionality. > 4. One or more roles may have more features/information on a page than > others. This would mean I have to customize role checking for every > page item. :-( For that I wrote a transformer. My pages contain statements of the form On encountering a cms:auth tag the transformer checks whether the user has that role. If so, it passes on the enclosed content. If not, it filters it. HTH Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: role-based access to pages and parts of pages - ideas?
Hi Helma, I would imagine the time in not on your side either -- at least it never is on mine ;-) It's hard to tell without seeing your sitemap, but it sounds like a lot of your problems come from that side. In theory things like authentication rules and adding new pages should involve little effort if the sitemap is right. I know this because I had to refactor it twice! I can take a look at it if you like -- maybe I'd be able to come up with some suggestions. Cheers, -Alex --- [EMAIL PROTECTED] wrote: > Hi Stefan and Alex, > > Both thank you very much for your ideas. I'll > comment on them below, not to > criticize you, but hoping that it will trigger more > ideas. > > Alex: I've looked at the portal code and it would > make me rewrite my current > cocoon application (which is still in the middle of > a rewrite of my previous > version :-( ). Also, for now I've done something > similar: add extra features > to a page that are only visible to administrators. > > Stefan: your approach comes close to what I was > thinking, but there are > several things I don't like in this setup: > 1. I have various roles (between 5 and 10) which > overlap in access > authentication, so every pipeline would need to > check for several roles and > if I need to add extra roles I need to revisit every > pipeline. :-( > 2. My sitemap is growing rapidly and by adding > enormous amounts of comment > I'm trying to keep it clear, but I find it more and > more difficult to find > what I'm looking for. So configuring authorisation > in the sitemap is not > really my idea of keeping it clear and separated. > 3. I want a general way of handling several pages, > i.e. with a minimal > number of pipelines. If in future I add a page, I > want it to be integrated > without touching the sitemap. I was thinking of > adding access rules to the > source of the form, but that would also spread the > authorization. :-( > 4. One or more roles may have more > features/information on a page than > others. This would mean I have to customize role > checking for every page > item. :-( > 5. Ideally I should add read/write access to data, > e.g. you're only allowed > to edit information you've entered yourself. I'll > skip this for now, but > I'll have to keep that in mind. > > Bye, Helma > > > > -Original Message- > > From: Stefan Klein [mailto:[EMAIL PROTECTED] > > Sent: Thursday, 08 January 2004 20:09 > > To: [EMAIL PROTECTED] > > Subject: Re: role-based access to pages and parts > of pages - ideas? > > > > > > Helma, > > > > > Any ideas? > > > > might not be of much use for you, cause I am not > using the > > authentication-fw, but I thought, I'd tell you > anyway. I am using a > > structure very much like the authentication-fw, > but using my > > own actions, > > thus a lot lighter and tailored exactly to my > needs (thus not > > as nice and > > flexible as the framework). > > > > There are actions for logging in, logging out, > authenticating and > > protecting, just like the framework.My sitemap > looks very much like > > the one in the authentication-example without flow > (thus not > > the one you > > adopted). > > > > Unlike the framework, my protecting action takes a > parameter > > "role" and > > it checks whether the user who is locked in has > that role. If > > so, access > > is granted. so something like: > > > > > > > > > > > > > > > > > > > > That way, I keep everything in the sitemap and my > actions. > > Also, I could > > do authorization depending on the url and the user > who is logged in, > > e.g.: > > > > > > > > > > > > > > > > > > Here everything in protected/admin could only be > accessed by > > users with > > role admin. > > > > > > HTH. Maybe you can derive an idea for your problem > from this. > > I am also > > happy to share the code, if you want to have a > look. > > > > Stefan > > > > > - > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > = Alex Romayev Software Architect http://www.romayev.com [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: role-based access to pages and parts of pages - ideas?
Hi Stefan and Alex, Both thank you very much for your ideas. I'll comment on them below, not to criticize you, but hoping that it will trigger more ideas. Alex: I've looked at the portal code and it would make me rewrite my current cocoon application (which is still in the middle of a rewrite of my previous version :-( ). Also, for now I've done something similar: add extra features to a page that are only visible to administrators. Stefan: your approach comes close to what I was thinking, but there are several things I don't like in this setup: 1. I have various roles (between 5 and 10) which overlap in access authentication, so every pipeline would need to check for several roles and if I need to add extra roles I need to revisit every pipeline. :-( 2. My sitemap is growing rapidly and by adding enormous amounts of comment I'm trying to keep it clear, but I find it more and more difficult to find what I'm looking for. So configuring authorisation in the sitemap is not really my idea of keeping it clear and separated. 3. I want a general way of handling several pages, i.e. with a minimal number of pipelines. If in future I add a page, I want it to be integrated without touching the sitemap. I was thinking of adding access rules to the source of the form, but that would also spread the authorization. :-( 4. One or more roles may have more features/information on a page than others. This would mean I have to customize role checking for every page item. :-( 5. Ideally I should add read/write access to data, e.g. you're only allowed to edit information you've entered yourself. I'll skip this for now, but I'll have to keep that in mind. Bye, Helma > -Original Message- > From: Stefan Klein [mailto:[EMAIL PROTECTED] > Sent: Thursday, 08 January 2004 20:09 > To: [EMAIL PROTECTED] > Subject: Re: role-based access to pages and parts of pages - ideas? > > > Helma, > > > Any ideas? > > might not be of much use for you, cause I am not using the > authentication-fw, but I thought, I'd tell you anyway. I am using a > structure very much like the authentication-fw, but using my > own actions, > thus a lot lighter and tailored exactly to my needs (thus not > as nice and > flexible as the framework). > > There are actions for logging in, logging out, authenticating and > protecting, just like the framework. My sitemap looks very much like > the one in the authentication-example without flow (thus not > the one you > adopted). > > Unlike the framework, my protecting action takes a parameter > "role" and > it checks whether the user who is locked in has that role. If > so, access > is granted. so something like: > > > > > > > > > > That way, I keep everything in the sitemap and my actions. > Also, I could > do authorization depending on the url and the user who is logged in, > e.g.: > > > > > > > > > Here everything in protected/admin could only be accessed by > users with > role admin. > > > HTH. Maybe you can derive an idea for your problem from this. > I am also > happy to share the code, if you want to have a look. > > Stefan > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: role-based access to pages and parts of pages - ideas?
Hi Helma, Here is a simplified version of what you can do with portal: 1. Define users and roles. 2. Define page modules, known as coplets or portlets 3. Define page templates and map coplets to where within the template they should appear. 4. Define user/role permissions in terms of which coplets they are allowed to see. 5. Define user/role permissions in terms of coplet layouts. 6. Allow users to customize portlets (for example, remove, minimize, maximize, etc). For example, I reuse pages on my website for regular users and adminitrators, but the administrators get to see extra portlets, which allow them to edit information. If your pages/portlets don't change and the only thing that changes is data, the portal is probably not what you need. Hope this helps, -Alex --- [EMAIL PROTECTED] wrote: > Hi, > > Thanks for the idea, but I don't think a portal is > really what I need. I > will look at how it's handled there. My application > is a medical application > where you first select a patient and then > enter/retrieve information for > that patient in views based on the current > paper-based forms. I think > introducing a portal now will make everything too > confusing for the users. > > Bye, Helma > > > -Original Message- > > From: Alex Romayev [mailto:[EMAIL PROTECTED] > > Sent: Thursday, 08 January 2004 17:34 > > To: [EMAIL PROTECTED] > > Subject: Re: role-based access to pages and parts > of pages - ideas? > > > > > > Have you considered using portal-fw or the new > portal > > engine? > > > > I am using portal-fw and authentication-fw to > protect > > pages (based on pattern matching) and construct > the > > pages out of coplets based on user/role > configuration. > > > > Cheers, > > -Alex > > > > --- [EMAIL PROTECTED] wrote: > > > Hi, > > > > > > Could anyone of you give some URLs or ideas > about > > > the best way to handle > > > role-based access to pages and parts of pages? > > > > > > I reworked the authentication-fw flow example > into > > > my webapp, so now I have > > > some user information available in a session. I > > > added the protect() function > > > to all pipelines that need protection and I'm > able > > > to include parts of pages > > > based on the role of the user. > > > > > > I could of course modify protect() to check the > role > > > and decide whether the > > > page can be accessed or not, but I feel I'm > > > spreading the authorization > > > information throughout the application and I'd > > > prefer to keep it together. > > > > > > Any ideas? > > > > > > Bye, > > > > > > Helma van der Linden > > > > > > > > > - > > > To unsubscribe, e-mail: > > > [EMAIL PROTECTED] > > > For additional commands, e-mail: > > > [EMAIL PROTECTED] > > > > > > > > > = > > Alex Romayev > > Software Architect > > http://www.romayev.com > > [EMAIL PROTECTED] > > > > > - > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > = Alex Romayev Software Architect http://www.romayev.com [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: role-based access to pages and parts of pages - ideas?
Helma, > Any ideas? might not be of much use for you, cause I am not using the authentication-fw, but I thought, I'd tell you anyway. I am using a structure very much like the authentication-fw, but using my own actions, thus a lot lighter and tailored exactly to my needs (thus not as nice and flexible as the framework). There are actions for logging in, logging out, authenticating and protecting, just like the framework.My sitemap looks very much like the one in the authentication-example without flow (thus not the one you adopted). Unlike the framework, my protecting action takes a parameter "role" and it checks whether the user who is locked in has that role. If so, access is granted. so something like: That way, I keep everything in the sitemap and my actions. Also, I could do authorization depending on the url and the user who is logged in, e.g.: Here everything in protected/admin could only be accessed by users with role admin. HTH. Maybe you can derive an idea for your problem from this. I am also happy to share the code, if you want to have a look. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: role-based access to pages and parts of pages - ideas?
Hi, Thanks for the idea, but I don't think a portal is really what I need. I will look at how it's handled there. My application is a medical application where you first select a patient and then enter/retrieve information for that patient in views based on the current paper-based forms. I think introducing a portal now will make everything too confusing for the users. Bye, Helma > -Original Message- > From: Alex Romayev [mailto:[EMAIL PROTECTED] > Sent: Thursday, 08 January 2004 17:34 > To: [EMAIL PROTECTED] > Subject: Re: role-based access to pages and parts of pages - ideas? > > > Have you considered using portal-fw or the new portal > engine? > > I am using portal-fw and authentication-fw to protect > pages (based on pattern matching) and construct the > pages out of coplets based on user/role configuration. > > Cheers, > -Alex > > --- [EMAIL PROTECTED] wrote: > > Hi, > > > > Could anyone of you give some URLs or ideas about > > the best way to handle > > role-based access to pages and parts of pages? > > > > I reworked the authentication-fw flow example into > > my webapp, so now I have > > some user information available in a session. I > > added the protect() function > > to all pipelines that need protection and I'm able > > to include parts of pages > > based on the role of the user. > > > > I could of course modify protect() to check the role > > and decide whether the > > page can be accessed or not, but I feel I'm > > spreading the authorization > > information throughout the application and I'd > > prefer to keep it together. > > > > Any ideas? > > > > Bye, > > > > Helma van der Linden > > > > > - > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > = > Alex Romayev > Software Architect > http://www.romayev.com > [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: role-based access to pages and parts of pages - ideas?
Have you considered using portal-fw or the new portal engine? I am using portal-fw and authentication-fw to protect pages (based on pattern matching) and construct the pages out of coplets based on user/role configuration. Cheers, -Alex --- [EMAIL PROTECTED] wrote: > Hi, > > Could anyone of you give some URLs or ideas about > the best way to handle > role-based access to pages and parts of pages? > > I reworked the authentication-fw flow example into > my webapp, so now I have > some user information available in a session. I > added the protect() function > to all pipelines that need protection and I'm able > to include parts of pages > based on the role of the user. > > I could of course modify protect() to check the role > and decide whether the > page can be accessed or not, but I feel I'm > spreading the authorization > information throughout the application and I'd > prefer to keep it together. > > Any ideas? > > Bye, > > Helma van der Linden > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > = Alex Romayev Software Architect http://www.romayev.com [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
role-based access to pages and parts of pages - ideas?
Hi, Could anyone of you give some URLs or ideas about the best way to handle role-based access to pages and parts of pages? I reworked the authentication-fw flow example into my webapp, so now I have some user information available in a session. I added the protect() function to all pipelines that need protection and I'm able to include parts of pages based on the role of the user. I could of course modify protect() to check the role and decide whether the page can be accessed or not, but I feel I'm spreading the authorization information throughout the application and I'd prefer to keep it together. Any ideas? Bye, Helma van der Linden - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
