I have patched WOComponentRequestHandler and created a pull request in the wonder/integration branch
then you will set the property: ERXDirectComponentAccessAllowed=false Amedeo On 10/apr/2012, at 15:14, Patrick Robinson wrote: > I'm pretty sure this "feature" is the only mechanism by which a user can > request a specific page (or component) by name. I would want to block > arbitrary access to pages as well as prevent spurious session creation. > > But yes, there are ways to mitigate the effects. If an authenticated "user" > is stored in the Session, then you can check for that before performing an > action in invokeAction() or returning a response in appendToResponse(). And > you *do* have to worry about invokeAction(), by the way: the presence of a > senderID in the URL causes the component action handler to initiate the > invokeAction phase. I suppose sessions with no authenticated user could even > be terminated at the same time. > > No end to the fun! > > - Patrick > > On Apr 10, 2012, at 2:43 AM, Cheong Hee (Gmail) wrote: > >> Hi Patrick >> >> The rationale I am asking is the way web technology is, I think we may not >> be able to block the arbitrary access of web pages. However, if we could >> use user authentication as a way to check, terminate the unwanted sessions >> and redirect to another stateless page, the impacts could be reduced. >> Correct me if wrong.. >> >> Cheers >> >> Cheong Hee >> >> ----- Original Message ----- From: "Cheong Hee (Gmail)" <[email protected]> >> To: "Patrick Robinson" <[email protected]> >> Cc: "WebObjects-Dev Mailing List" <[email protected]> >> Sent: Tuesday, April 10, 2012 12:53 PM >> Subject: Re: preventing direct component access >> >> >>> Hi Patrick >>> >>> This is an interesting old issue. Just curious, what will be your ultimate >>> ideal resolution to this? Bar the access of the page, or reduce the >>> redundant sessions creation or something else ... >>> >>> Cheers >>> >>> Cheong Hee >>> >>> ----- Original Message ----- From: "Patrick Robinson" <[email protected]> >>> To: "Amedeo Mantica" <[email protected]> >>> Cc: "WebObjects-Dev Mailing List" <[email protected]> >>> Sent: Tuesday, April 10, 2012 4:52 AM >>> Subject: Re: preventing direct component access >>> >>> >>>> That code represents the per-app version of the "conventional wisdom" that >>>> I started out questioning, below. The problem with this is that the user >>>> can specifiy a "senderID" (as in the URL I gave there), and then >>>> senderID() will *not* return null; in the case below, it'll be "99". >>>> >>>> >>>> On Apr 9, 2012, at 4:48 PM, Amedeo Mantica wrote: >>>> >>>>> Try this in your Application.java: >>>>> >>>>> public WOComponent pageWithName(String pageName, WOContext context) >>>>> { >>>>> if((context.senderID()==null)&&(componentRequestHandlerKey().equals(context.request().requestHandlerKey()))) >>>>> { >>>>> log.error("Direct Access attempt"); >>>>> pageName="Main"; >>>>> } >>>>> return super.pageWithName(pageName, context); >>>>> >>>>> } >>>>> >>>>> >>>>> >>>>> On 09/apr/2012, at 21:59, Mike Schrag wrote: >>>>> >>>>>> Yeah, you're right ... might be kind of a pain in the butt to fix >>>>>> without hackery then :) >>>>>> >>>>>> On Apr 9, 2012, at 3:41 PM, Patrick Robinson wrote: >>>>>> >>>>>>> But it doesn't even have to have the ".wo" on the end of the page name >>>>>>> for this hack to work. If the app has a "SecretPage.wo" component, >>>>>>> then a URL like this will instantiate and return it: >>>>>>> >>>>>>> https://myhost.mydomain/cgi-bin/WebObjects/MyApp.woa/wo/SecretPage//88.99 >>>>>>> >>>>>>> - Patrick >>>>>>> >>>>>>> >>>>>>> On Apr 9, 2012, at 10:10 AM, Mike Schrag wrote: >>>>>>> >>>>>>>> probably just catch any time you have a ".wo" in your URL and throw >>>>>>>> ... you could do it in the url rewriter or something. i don't think >>>>>>>> there's ever any reason to have a .wo reference in a normal app. >>>>>>>> >>>>>>>> ms >>>>>>>> >>>>>>>> On Apr 9, 2012, at 10:00 AM, Patrick Robinson wrote: >>>>>>>> >>>>>>>>> Yeah, that _does_ sound rather annoying! :-P >>>>>>>>> >>>>>>>>> Is there a perhaps less-annoying way to approximate similar behavior? >>>>>>>>> >>>>>>>>> >>>>>>>>> On Apr 5, 2012, at 2:46 PM, Mike Schrag wrote: >>>>>>>>> >>>>>>>>>> I changed this in WO core, and unfortunately it's kind of annoying >>>>>>>>>> to fix without some hackery, but in WOComponentRequestHandler, >>>>>>>>>> there's a static method requestHandlerValuesForRequest ... That >>>>>>>>>> dictionary has a key named "wopage" in it. If you did some class >>>>>>>>>> rewriting (with like gluonj or something), you could change that >>>>>>>>>> static method to remove the wopage key ... That MIGHT be enough to >>>>>>>>>> do it. >>>>>>>>>> >>>>>>>>>> On Apr 5, 2012, at 2:39 PM, Patrick Robinson wrote: >>>>>>>>>> >>>>>>>>>>> I've stumbled across a wrinkle re: what I had assumed to be the >>>>>>>>>>> conventional wisdom for preventing direct access to component pages >>>>>>>>>>> via URLs like the following: >>>>>>>>>>> >>>>>>>>>>> http://myhost.mydomain/cgi-bin/WebObjects/MyApp.woa/-9876/wo/SecretPage.wo >>>>>>>>>>> >>>>>>>>>>> It's an old, old WO problem, and I'm wondering what other people do >>>>>>>>>>> to handle it. >>>>>>>>>>> >>>>>>>>>>> I've always figured the best idea is to just configure the web >>>>>>>>>>> server to catch WO URLs that end in /wo/(.+)\.wo and rewrite or >>>>>>>>>>> redirect them. Another potential approach is to try to recognize >>>>>>>>>>> and catch such requests in the app itself, somewhere like the >>>>>>>>>>> Application class's pageWithName. The problem is, these solutions >>>>>>>>>>> don't catch all the sneaky ways of slipping in a back door. >>>>>>>>>>> >>>>>>>>>>> Consider: >>>>>>>>>>> >>>>>>>>>>> http://myhost.mydomain/cgi-bin/WebObjects/MyApp.woa/-9876/wo/SecretPage.wo//1.2 >>>>>>>>>>> >>>>>>>>>>> This ends up with Application's pageWithName trying to create a >>>>>>>>>>> page with the name "SecretPage". A new session has already been >>>>>>>>>>> created somewhere down inside the component request handler, it'll >>>>>>>>>>> have a WOContext with a contextID of 0, and the senderID will be 2. >>>>>>>>>>> You'd be hard-pressed to know that you shouldn't allow the page >>>>>>>>>>> creation to proceed. >>>>>>>>>>> >>>>>>>>>>> You could try to change the web server's search pattern to also >>>>>>>>>>> catch a slash followed by more characters after the ".wo", but >>>>>>>>>>> you'd have to be careful not to disallow sessionIDs that just >>>>>>>>>>> happen to end in "wo". And even if you could reliably block the >>>>>>>>>>> above, the hacker could try this: >>>>>>>>>>> >>>>>>>>>>> http://myhost.mydomain/cgi-bin/WebObjects/MyApp.woa/-9876/wo/SecretPage.wox//1.2 >>>>>>>>>>> (that is, add more characters after the ".wo") >>>>>>>>>>> >>>>>>>>>>> Now that doesn't fit the pattern at all, and gets hung up in the >>>>>>>>>>> Application's pageWithName, where a way-too-informative >>>>>>>>>>> WOPageNotFoundException is thrown. Of course, you'd catch that >>>>>>>>>>> somewhere like handleException(). Doesn't quite seem like the >>>>>>>>>>> right approach, either. >>>>>>>>>>> >>>>>>>>>>> My point here is, there are more ways of hacking a WebObjects URL >>>>>>>>>>> than I had previously considered. Does anyone have what they >>>>>>>>>>> consider to be an ironclad solution to this problem? >>>>>>>>>>> >>>>>>>>>>> (I hate it when I discover stuff I thought I had dealt with 10 >>>>>>>>>>> years ago is still biting me.) >>>>>>>>>>> >>>>>>>>>>> - Patrick >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Do not post admin requests to the list. They will be ignored. >>>>>>>>>>> Webobjects-dev mailing list ([email protected]) >>>>>>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>>>>>> https://lists.apple.com/mailman/options/webobjects-dev/mschrag%40pobox.com >>>>>>>>>>> >>>>>>>>>>> This email sent to [email protected] >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Do not post admin requests to the list. They will be ignored. >>>>>> Webobjects-dev mailing list ([email protected]) >>>>>> Help/Unsubscribe/Update your Subscription: >>>>>> https://lists.apple.com/mailman/options/webobjects-dev/amedeomantica%40me.com >>>>>> >>>>>> This email sent to [email protected] >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Do not post admin requests to the list. They will be ignored. >>>> Webobjects-dev mailing list ([email protected]) >>>> Help/Unsubscribe/Update your Subscription: >>>> https://lists.apple.com/mailman/options/webobjects-dev/chng34%40gmail.com >>>> >>>> This email sent to [email protected] >>>> >> > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/amedeomantica%40me.com > > This email sent to [email protected]
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
