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]
