On 11/04/2012, at 3:31 AM, Amedeo Mantica wrote:
> I have patched WOComponentRequestHandler and created a pull request in the
> wonder/integration branch
>
> then you will set the property:
>
> ERXDirectComponentAccessAllowed=false
You might want to add that property to the default project tem
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
o 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 termin
pr 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
012, 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
mail) 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
>>>&g
>> 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 M
y 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.
>
ed.
>>> Correct me if wrong..
>>>
>>> Cheers
>>>
>>> Cheong Hee
>>>
>>> - Original Message - From: "Cheong Hee (Gmail)"
>>> To: "Patrick Robinson"
>>> Cc: "WebObjects-Dev Mailing Lis
ould be reduced.
>> Correct me if wrong..
>>
>> Cheers
>>
>> Cheong Hee
>>
>> - Original Message - From: "Cheong Hee (Gmail)"
>> To: "Patrick Robinson"
>> Cc: "WebObjects-Dev Mailing List"
>> Sen
Cc: "WebObjects-Dev Mailing List"
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 redun
gt;
> Cheers
>
> Cheong Hee
>
> - Original Message - From: "Cheong Hee (Gmail)"
> To: "Patrick Robinson"
> Cc: "WebObjects-Dev Mailing List"
> Sent: Tuesday, April 10, 2012 12:53 PM
> Subject: Re: preventing direct component acc
be reduced.
Correct me if wrong..
Cheers
Cheong Hee
- Original Message -
From: "Cheong Hee (Gmail)"
To: "Patrick Robinson"
Cc: "WebObjects-Dev Mailing List"
Sent: Tuesday, April 10, 2012 12:53 PM
Subject: Re: preventing direct component access
Hi P
quot;
To: "Amedeo Mantica"
Cc: "WebObjects-Dev Mailing List"
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
On Apr 5, 2012, at 11:39 AM, Patrick Robinson wrote:
> 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?
D2W ;-)
Ramsey
_
Yes, true
I didn't noticed. Is very bad
Amedeo
On 09/apr/2012, at 22:52, Patrick Robinson wrote:
> 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
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, 2
Try this in your Application.java:
public WOComponent pageWithName(String pageName, WOContext context)
{
if((context.senderID()==null)&&(componentRequestHandlerKey().equals(context.request().requestHandlerKey(
{
log.error
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
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
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 anno
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 WOComponentRequestHandle
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 someth
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
24 matches
Mail list logo
