RE: URL pattern /admin/*

Hi Christian,

Yes, I think it would be really helpful to have the app gateway store the path information somewhere near the event. Currently we are parsing the URI second time in order to get this path.

Our security scheme is somehow cross between the Barracuda' way and the "standard" way:

- we map allowed event patterns on security roles in web.xml

- we define base events classes, something like CommonEvent, 
  UserManagementEvent, SysAdminEvent, etc. Concrete 
  application events are extending these base classes.

- we define a mapping between the base event classes and path 
  patterns:
      CommonEvent=Common
      SysAdminEvent=SysAdmin
      ...
  where the right part is the path (i.e. /Common/Login.event)

Now, when the event arrives, we only permit the events with the correct path prefix (defined by our event class to path map). The rest will be handled by the servlet container - security role check, login forms, session time-outs, etc.

This scheme works well for us. Need to maintain the event-to-path map could be seen as a bad idea, but in our case, the simple XSLT script construct this map directly from the events.xml file during the build.


Sergey


-----Original Message-----
From: Christian Cryder [mailto:[email protected]]
Sent: Wednesday, January 15, 2003 5:17 PM
To: [email protected]
Subject: RE: [Barracuda] URL pattern /admin/*


Hi Sergey,

I'd be interested in seeing how you did this...I'm guessing that maybe what
the application gateway should do is always get the event name from the URI,
but then if there is path information accompanying the request to also tack
that onto the event object somehow.

So let us know how you did it...

Christian
----------------------------------------------
Christian Cryder [[email protected]]
Internet Architect, ATMReports.com
Barracuda - http://barracuda.enhydra.org
----------------------------------------------
"Coffee? I could quit anytime, just not today"

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Udovenko Sergey
> Sent: Wednesday, January 15, 2003 9:02 AM
> To: [email protected]
> Subject: RE: [Barracuda] URL pattern /admin/*
>
>
>
> We also using the path prefix before the events in our project. Our
> security implementation relay on these prefixes.
> Currently we have more than 10 security patterns defined. Describing
> these patterns in the web.xml makes it possible to restrict access to
> the events (and screens) in quite flexible way.
>
> The only problem here - current Barracuda implementation discards these
> prefixes, so we had to override ApplicationGateway class in order to
> preserve them.
>
> May be it would be helpful to have some more support from Barracuda
> here?
>
>
> Sergey.
>
>
>
> -----Original Message-----
> From: Andras Balogh [mailto:[email protected]]
> Sent: Wednesday, January 15, 2003 4:50 PM
> To: [email protected]
> Subject: Re: [Barracuda] URL pattern /admin/*
>
>
>
> ----- Original Message -----
> From: "Christian Cryder" <[email protected]>
> To: <[email protected]>
> Sent: Wednesday, January 15, 2003 17:33
> Subject: RE: [Barracuda] URL pattern /admin/*
>
>
> > Hi Andras,
> >
> > Well, the way things are currently implemented, anything that ends
> with
> > *.event gets routed to ApplicationGateway (which youy are seeing), and
> > ApplicationGateway then tries to determine the event name. It does
> this
> > first by looking at the servlet path info, and if that is null, then
> it
> uses
> > the actual URI name. In this case, the path is coming back as 'admin',
> and
> > so Barracuda thinks that is the event name you are after (which it
> isn't).
> >
> > Before I venture a guess at possible solutions, can you give us soime
> > insight into what you are trying to accomplish here? Why do you want
> to
> use
> > the /admin path to precede the actual event? Why not just use the
> event
> > name? Or perhaps something like
> > http://myhost/mywebapp/GetLogin.event?Admin=true
> >
> > Help us understand what you're after here...
> >
> > Thanks,
> > Christian
> > ----------------------------------------------
> > Christian Cryder [[email protected]]
> > Internet Architect, ATMReports.com
> > Barracuda - http://barracuda.enhydra.org
> > ----------------------------------------------
> > "Coffee? I could quit anytime, just not today"
> >
>
>     Hi,
>
> Thank you for answering.
> So here is what i am trying to do, i have a webapp that has an admin
> part
> and a public part. I want to separate these 2 parts as much as possible
> so i
> have
> different event.xml files, different application gateways etc.
> Now one choice would be i guess to name the public events and admin
> events
> differently like *.event and *.aevent   but i don't like this solution.
> I need the admin events accessed only with path /admin/ to can apply
> further
> security constraints to a certain path (in my case /admin/) if it will
> be
> necessary.
>
> I think the majority of webapps have an admin part and a public part.
> How do you separate these parts?
>
> Thanks,
> Andras.
>
>
>
>
>
>
>
> _______________________________________________
> Barracuda mailing list
> [email protected]
> http://barracudamvc.org/lists/listinfo/barracuda
>
> This message is for the named person's use only. It may contain
> confidential, proprietary or legally privileged information. No
> confidentiality or privilege is waived or lost by any mistransmission.
> If you receive this message in error, please notify the sender urgently
> and then immediately delete the message and any copies of it from your
> system. Please also immediately destroy any hardcopies of the message.
> You must not, directly or indirectly, use, disclose, distribute, print,
> or copy any part of this message if you are not the intended recipient.
> The sender's company reserves the right to monitor all e-mail
> communications through their networks. Any views expressed in this
> message are those of the individual sender, except where the message
> states otherwise and the sender is authorised to state them to be the
> views of the sender's company.
> _______________________________________________
> Barracuda mailing list
> [email protected]
> http://barracudamvc.org/lists/listinfo/barracuda

_______________________________________________
Barracuda mailing list
[email protected]
http://barracudamvc.org/lists/listinfo/barracuda