Thanks again for that. I hadn't realized it was that easy, or I'd have done it myself. Maybe next time! :-)
- Patrick On Apr 10, 2012, at 2:15 PM, Amedeo Mantica wrote: > I originally replaced the WOComponentRequestHandler (get loaded in the > classpath before the WO one) > > After Ramsey Suggestion I renamed and moved to ERXComponentRequestHandler, > then patched ERXApplication to assign ERXComponentRequestHandler to the > componenthandler key > > Amedeo > > On 10/apr/2012, at 20:10, Ramsey Gurley wrote: > >> Probably should be ERX to be consistent. Yeah, WO is very pluggable. You can >> register your own request handlers for any request handler key. Make up your >> own request handlers and keys if you like. >> >> WOApplication app = WOApplication.application(); >> app.registerRequestHandler(new ERXComponentRequestHandler(), >> app.componentRequestHandlerKey()); >> >> Problem solved. >> >> Ramsey >> >> >> On Apr 10, 2012, at 10:56 AM, Patrick Robinson wrote: >> >>> Good idea, so far as I understand it. I've not yet quite grasped the >>> distinction between the ER classes vs. the ERX classes. >>> >>> Also, would you register the new handler with the same old request handler >>> key? >>> >>> >>> On Apr 10, 2012, at 1:47 PM, Ramsey Gurley wrote: >>> >>>> Commented already >>>> >>>> https://github.com/projectwonder/wonder/pull/150 >>>> >>>> On Apr 10, 2012, at 10:33 AM, Pascal Robert wrote: >>>> >>>>> >>>>> Le 2012-04-10 à 13:29, Amedeo Mantica a écrit : >>>>> >>>>>> I have patched WOComponentRequestHandler and created a pull request in >>>>>> the wonder/integration branch >>>>>> >>>>>> then you will set the property: >>>>>> >>>>>> ERXDirectComponentAccessAllowed=false >>>>> >>>>> If someone wants to review it: >>>>> >>>>> https://github.com/projectwonder/wonder/pull/150/files >>>>> >>>>>> 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/rgurley%40smarthealth.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]
