Much ado about nothing ;-) On Apr 10, 2012, at 11:20 AM, Patrick Robinson wrote:
> 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]
