Re: Re: Re: Url rewriting of .action to .jsp

[Ken McWilliams]

Sorry that was confusing. A new ModelDriven Interface would be better.

ModelFacing from an Implementation perspective:
- push the Model object to the top of the stack such that members can be
set directly (same as model driven)
- register a pre-result listener, which will revert the action class to
being at the top of the stack.


ModelBacking
- Leave the model as is
- Register a pre-result listener, which will push the object specified in
ModelBacking to the top of the value stack.

Since the later functionality is readily achieved using  there is
not much need for the second. But someone recently was talking about
managing legacy views
 and this sort of decoupling might have minor use in that case. It could
also have use with Struts results which expect a certain object, but then
using the appropriate interface directly on the action is more obvious.
Another possible use is for security. Certain results can serialize the
action, a decoupling here could be useful (on action uses the same class
for a JSP view, an XML producing result and a JSON producing result). In
this case having the opportunity to create an object against which the view
will only have access could make what people are supposed to have access to
clearer and allow the serializers to cleanly operate over the whole object
rather than having to use there APIs to prune parts of the tree.

Hope this is clearer. I don't know if it is just me. I like the idea of
ModelDriven but find that having the same model for the front and the back
too restrictive. After all the general flow in most actions is: Get data,
execute business logic, marshal data for view, possibly some processing of
view data...

How often do we want to send the same type of object back to the view we
just received?  Not that often.


On Mon, Sep 30, 2013 at 2:26 AM, Lukasz Lenart wrote:

> @Ken I'm bit lost with your mails, right now I don't know what you
> want - new Model interfaces or current ModelDriven approach is valid?
> Maybe start a new discussion?
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> 2013/9/26 Ken McWilliams :
> > ...more often than not, NOT what I want (wrt: "Maybe it's just me but for
> > some reason this is more often than not what I want (I want the model
> > towards the request but not towards the view), so I need to forgo
> > ModelDriven."). Sorry everyone!
> >
> >
> > On Wed, Sep 25, 2013 at 7:39 PM, Ken McWilliams <
> ken.mcwilli...@gmail.com>wrote:
> >
> >> Sorry should have read the last couple lines before posting! It was in
> >> defense of ModelBacking suggesting that the congruent structure could
> allow
> >> us to publish the action into the stack and then handle it knowing the
> >> interface. A certain result type for instance could require a specific
> >> backing model to even handle the request (could include it in the plugin
> >> for that request, as a way to clearly make you satisfy it's
> requirements).
> >>
> >> Seems to be in the actions scope. Get data, validate data, invoke
> business
> >> logic, marshal data for view (massage data for view if required). If
> would
> >> fall under the latter.
> >>
> >>
> >> On Wed, Sep 25, 2013 at 7:32 PM, Ken McWilliams <
> ken.mcwilli...@gmail.com>wrote:
> >>
> >>> Not sure if this is the place to bring this up, this is an annoyance
> >>> coming from ModelDriven may offer a solution...
> >>>
> >>> Issue: It's hard to get past the model if you want to add more
> attributes
> >>> to the action. Also when using ModelDriven the same view of the action
> is
> >>> applied from the HTTP side as the views side. Maybe it's just me but
> for
> >>> some reason this is more often than not what I want (I want the model
> >>> towards the request but not towards the view), so I need to forgo
> >>> ModelDriven.
> >>>
> >>> What I though might be interesting is a ModelFacing and
> >>> ModelBacking interfaces.
> >>>
> >>> ModelFacing provides the same functionality as ModelDriven but only
> >>> towards the request. Any other methods defined in the action are not
> >>> accessible. ModelBacking isn't so interesting, same effect could be
> >>> achieved using s:push tag I suppose, so the later isn't needed so
> much. But
> >>> it wouldn't to have the later because should we want to expose an
> interface
> >>> via OGNL we could say some component provides X interface and it would
> be
> >>> available from the value stack that way without needing a view. It's
> pretty
> >>> obvious how conventions could determine the white listed methods from
> this.
> >>>
> >>>
> >>> On Tue, Sep 24, 2013 at 3:21 AM, Lukasz Lenart <
> lukaszlen...@apache.org>wrote:
> >>>
>  2013/9/24 Christoph Nenning :
>  >> > But still: method:add works while !add does not.
>  >>
>  >> If you could prepare a small demo app, I'd like investigate that.
>  >>
>  >>
>  >
>  > I can do so next week, sorry for the delay
> 
>  No problem, I'm busy too ;-)
> 
> 
>  Regards
>  

Re: Url rewriting of .action to .jsp

[Lukasz Lenart]

2013/9/22 Lukasz Lenart :
> You should never ever allow to access JSPs directly! Thus can be
> potential security risk!
>
> What you want to achieve are two actions:
> - login-form.action to display login form
> - login.action to submit login form to and perform validation/user login

There is one more option: login!input - as input method is skip during
validation - check struts-default.xml and defaultStack definition. Or
read docs ;-)

http://struts.apache.org/development/2.x/docs/validation.html#Validation-TurningonValidation


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Re: Re: strict DMI, was: Url rewriting of .action to .jsp

[Lukasz Lenart]

Done

https://cwiki.apache.org/confluence/display/WW/Action+Configuration#ActionConfiguration-DynamicMethodInvocation

2013/10/1 Christoph Nenning :
>> >
>> > Would you please have a look at the sample app and tell me what I am
> doing
>> > wrong?
>> >
>> >
> https://github.com/wolpi/struts2-samples/tree/master/dmiandactionmappingtest
>
>>
>> 
>>
>> It must be true, if false whole DMI logic is off.
>>
>> > class="struts2.samples.dmiandactionmappingtest.actions.HelloAction">
>>
>> Removed method={1} as you don't use "*" mapping
>>
>> add
>>
>> In this way you define allowed methods.
>>
>
> Okay, now even I understand it, thanks a lot.
>
> Would you mind adding that sample struts.xml in the wiki, that I can find
> it next time I need it?
>
>
>> > Next question is: how to use strict DMI with convention plugin?
>>
>> Not yet, I will add it soon.
>>
>>
>
> Looking forward to it
>
>
> Regards,
> Christoph
>
> This Email was scanned by Sophos Anti Virus

-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Antwort: Re: strict DMI, was: Url rewriting of .action to .jsp

[Christoph Nenning]

> >
> > Would you please have a look at the sample app and tell me what I am 
doing
> > wrong?
> >
> > 
https://github.com/wolpi/struts2-samples/tree/master/dmiandactionmappingtest

> 
> 
> 
> It must be true, if false whole DMI logic is off.
> 
>  class="struts2.samples.dmiandactionmappingtest.actions.HelloAction">
> 
> Removed method={1} as you don't use "*" mapping
> 
> add
> 
> In this way you define allowed methods.
> 

Okay, now even I understand it, thanks a lot.

Would you mind adding that sample struts.xml in the wiki, that I can find 
it next time I need it?


> > Next question is: how to use strict DMI with convention plugin?
> 
> Not yet, I will add it soon.
> 
> 

Looking forward to it


Regards,
Christoph

This Email was scanned by Sophos Anti Virus

Re: strict DMI, was: Url rewriting of .action to .jsp

[Lukasz Lenart]

2013/9/30 Christoph Nenning :
> Finally I continued with my strict DMI tests.
>
> While creating a sample app I discovered that the above was wrong. It is a
> CSRF protection interceptor in the other app which made me think that !add
> was blocked by the framework.
>
>
> But I could not get strict DMI working at all. Only execute() got invoked,
> no matter what I tried.
>
>
> Would you please have a look at the sample app and tell me what I am doing
> wrong?
>
> https://github.com/wolpi/struts2-samples/tree/master/dmiandactionmappingtest



It must be true, if false whole DMI logic is off.



Removed method={1} as you don't use "*" mapping

add

In this way you define allowed methods.

> Next question is: how to use strict DMI with convention plugin?

Not yet, I will add it soon.


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Re: strict DMI, was: Url rewriting of .action to .jsp

[Christoph Nenning]

> >> > But still: method:add works while !add does not.
> >>
> >> If you could prepare a small demo app, I'd like investigate that.
> >>
> >>
> >
> > I can do so next week, sorry for the delay
> 
> No problem, I'm busy too ;-)
> 
> 

Finally I continued with my strict DMI tests.

While creating a sample app I discovered that the above was wrong. It is a 
CSRF protection interceptor in the other app which made me think that !add 
was blocked by the framework.


But I could not get strict DMI working at all. Only execute() got invoked, 
no matter what I tried.


Would you please have a look at the sample app and tell me what I am doing 
wrong?

https://github.com/wolpi/struts2-samples/tree/master/dmiandactionmappingtest


Next question is: how to use strict DMI with convention plugin?



Regards,
Christoph

This Email was scanned by Sophos Anti Virus

Re: Re: Re: Url rewriting of .action to .jsp

[Lukasz Lenart]

@Ken I'm bit lost with your mails, right now I don't know what you
want - new Model interfaces or current ModelDriven approach is valid?
Maybe start a new discussion?


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

2013/9/26 Ken McWilliams :
> ...more often than not, NOT what I want (wrt: "Maybe it's just me but for
> some reason this is more often than not what I want (I want the model
> towards the request but not towards the view), so I need to forgo
> ModelDriven."). Sorry everyone!
>
>
> On Wed, Sep 25, 2013 at 7:39 PM, Ken McWilliams 
> wrote:
>
>> Sorry should have read the last couple lines before posting! It was in
>> defense of ModelBacking suggesting that the congruent structure could allow
>> us to publish the action into the stack and then handle it knowing the
>> interface. A certain result type for instance could require a specific
>> backing model to even handle the request (could include it in the plugin
>> for that request, as a way to clearly make you satisfy it's requirements).
>>
>> Seems to be in the actions scope. Get data, validate data, invoke business
>> logic, marshal data for view (massage data for view if required). If would
>> fall under the latter.
>>
>>
>> On Wed, Sep 25, 2013 at 7:32 PM, Ken McWilliams 
>> wrote:
>>
>>> Not sure if this is the place to bring this up, this is an annoyance
>>> coming from ModelDriven may offer a solution...
>>>
>>> Issue: It's hard to get past the model if you want to add more attributes
>>> to the action. Also when using ModelDriven the same view of the action is
>>> applied from the HTTP side as the views side. Maybe it's just me but for
>>> some reason this is more often than not what I want (I want the model
>>> towards the request but not towards the view), so I need to forgo
>>> ModelDriven.
>>>
>>> What I though might be interesting is a ModelFacing and
>>> ModelBacking interfaces.
>>>
>>> ModelFacing provides the same functionality as ModelDriven but only
>>> towards the request. Any other methods defined in the action are not
>>> accessible. ModelBacking isn't so interesting, same effect could be
>>> achieved using s:push tag I suppose, so the later isn't needed so much. But
>>> it wouldn't to have the later because should we want to expose an interface
>>> via OGNL we could say some component provides X interface and it would be
>>> available from the value stack that way without needing a view. It's pretty
>>> obvious how conventions could determine the white listed methods from this.
>>>
>>>
>>> On Tue, Sep 24, 2013 at 3:21 AM, Lukasz Lenart 
>>> wrote:
>>>
 2013/9/24 Christoph Nenning :
 >> > But still: method:add works while !add does not.
 >>
 >> If you could prepare a small demo app, I'd like investigate that.
 >>
 >>
 >
 > I can do so next week, sorry for the delay

 No problem, I'm busy too ;-)


 Regards
 --
 Łukasz
 + 48 606 323 122 http://www.lenart.org.pl/

 -
 To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
 For additional commands, e-mail: user-h...@struts.apache.org


>>>
>>

-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Re: Re: Re: Url rewriting of .action to .jsp

[Ken McWilliams]

...more often than not, NOT what I want (wrt: "Maybe it's just me but for
some reason this is more often than not what I want (I want the model
towards the request but not towards the view), so I need to forgo
ModelDriven."). Sorry everyone!


On Wed, Sep 25, 2013 at 7:39 PM, Ken McWilliams wrote:

> Sorry should have read the last couple lines before posting! It was in
> defense of ModelBacking suggesting that the congruent structure could allow
> us to publish the action into the stack and then handle it knowing the
> interface. A certain result type for instance could require a specific
> backing model to even handle the request (could include it in the plugin
> for that request, as a way to clearly make you satisfy it's requirements).
>
> Seems to be in the actions scope. Get data, validate data, invoke business
> logic, marshal data for view (massage data for view if required). If would
> fall under the latter.
>
>
> On Wed, Sep 25, 2013 at 7:32 PM, Ken McWilliams 
> wrote:
>
>> Not sure if this is the place to bring this up, this is an annoyance
>> coming from ModelDriven may offer a solution...
>>
>> Issue: It's hard to get past the model if you want to add more attributes
>> to the action. Also when using ModelDriven the same view of the action is
>> applied from the HTTP side as the views side. Maybe it's just me but for
>> some reason this is more often than not what I want (I want the model
>> towards the request but not towards the view), so I need to forgo
>> ModelDriven.
>>
>> What I though might be interesting is a ModelFacing and
>> ModelBacking interfaces.
>>
>> ModelFacing provides the same functionality as ModelDriven but only
>> towards the request. Any other methods defined in the action are not
>> accessible. ModelBacking isn't so interesting, same effect could be
>> achieved using s:push tag I suppose, so the later isn't needed so much. But
>> it wouldn't to have the later because should we want to expose an interface
>> via OGNL we could say some component provides X interface and it would be
>> available from the value stack that way without needing a view. It's pretty
>> obvious how conventions could determine the white listed methods from this.
>>
>>
>> On Tue, Sep 24, 2013 at 3:21 AM, Lukasz Lenart 
>> wrote:
>>
>>> 2013/9/24 Christoph Nenning :
>>> >> > But still: method:add works while !add does not.
>>> >>
>>> >> If you could prepare a small demo app, I'd like investigate that.
>>> >>
>>> >>
>>> >
>>> > I can do so next week, sorry for the delay
>>>
>>> No problem, I'm busy too ;-)
>>>
>>>
>>> Regards
>>> --
>>> Łukasz
>>> + 48 606 323 122 http://www.lenart.org.pl/
>>>
>>> -
>>> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
>>> For additional commands, e-mail: user-h...@struts.apache.org
>>>
>>>
>>
>

Re: Re: Re: Url rewriting of .action to .jsp

[Ken McWilliams]

Sorry should have read the last couple lines before posting! It was in
defense of ModelBacking suggesting that the congruent structure could allow
us to publish the action into the stack and then handle it knowing the
interface. A certain result type for instance could require a specific
backing model to even handle the request (could include it in the plugin
for that request, as a way to clearly make you satisfy it's requirements).

Seems to be in the actions scope. Get data, validate data, invoke business
logic, marshal data for view (massage data for view if required). If would
fall under the latter.


On Wed, Sep 25, 2013 at 7:32 PM, Ken McWilliams wrote:

> Not sure if this is the place to bring this up, this is an annoyance
> coming from ModelDriven may offer a solution...
>
> Issue: It's hard to get past the model if you want to add more attributes
> to the action. Also when using ModelDriven the same view of the action is
> applied from the HTTP side as the views side. Maybe it's just me but for
> some reason this is more often than not what I want (I want the model
> towards the request but not towards the view), so I need to forgo
> ModelDriven.
>
> What I though might be interesting is a ModelFacing and ModelBacking
> interfaces.
>
> ModelFacing provides the same functionality as ModelDriven but only
> towards the request. Any other methods defined in the action are not
> accessible. ModelBacking isn't so interesting, same effect could be
> achieved using s:push tag I suppose, so the later isn't needed so much. But
> it wouldn't to have the later because should we want to expose an interface
> via OGNL we could say some component provides X interface and it would be
> available from the value stack that way without needing a view. It's pretty
> obvious how conventions could determine the white listed methods from this.
>
>
> On Tue, Sep 24, 2013 at 3:21 AM, Lukasz Lenart wrote:
>
>> 2013/9/24 Christoph Nenning :
>> >> > But still: method:add works while !add does not.
>> >>
>> >> If you could prepare a small demo app, I'd like investigate that.
>> >>
>> >>
>> >
>> > I can do so next week, sorry for the delay
>>
>> No problem, I'm busy too ;-)
>>
>>
>> Regards
>> --
>> Łukasz
>> + 48 606 323 122 http://www.lenart.org.pl/
>>
>> -
>> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
>> For additional commands, e-mail: user-h...@struts.apache.org
>>
>>
>

Re: Re: Re: Url rewriting of .action to .jsp

[Ken McWilliams]

Not sure if this is the place to bring this up, this is an annoyance coming
from ModelDriven may offer a solution...

Issue: It's hard to get past the model if you want to add more attributes
to the action. Also when using ModelDriven the same view of the action is
applied from the HTTP side as the views side. Maybe it's just me but for
some reason this is more often than not what I want (I want the model
towards the request but not towards the view), so I need to forgo
ModelDriven.

What I though might be interesting is a ModelFacing and ModelBacking
interfaces.

ModelFacing provides the same functionality as ModelDriven but only towards
the request. Any other methods defined in the action are not accessible.
ModelBacking isn't so interesting, same effect could be achieved using
s:push tag I suppose, so the later isn't needed so much. But it wouldn't to
have the later because should we want to expose an interface via OGNL we
could say some component provides X interface and it would be available
from the value stack that way without needing a view. It's pretty obvious
how conventions could determine the white listed methods from this.


On Tue, Sep 24, 2013 at 3:21 AM, Lukasz Lenart wrote:

> 2013/9/24 Christoph Nenning :
> >> > But still: method:add works while !add does not.
> >>
> >> If you could prepare a small demo app, I'd like investigate that.
> >>
> >>
> >
> > I can do so next week, sorry for the delay
>
> No problem, I'm busy too ;-)
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> -
> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
> For additional commands, e-mail: user-h...@struts.apache.org
>
>

Re: Re: Re: Url rewriting of .action to .jsp

[Lukasz Lenart]

2013/9/24 Christoph Nenning :
>> > But still: method:add works while !add does not.
>>
>> If you could prepare a small demo app, I'd like investigate that.
>>
>>
>
> I can do so next week, sorry for the delay

No problem, I'm busy too ;-)


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Re: Re: Re: Url rewriting of .action to .jsp

[Christoph Nenning]

> > But still: method:add works while !add does not.
> 
> If you could prepare a small demo app, I'd like investigate that.
> 
> 

I can do so next week, sorry for the delay

This Email was scanned by Sophos Anti Virus

Re: Re: Re: Url rewriting of .action to .jsp

[Lukasz Lenart]

2013/9/24 Christoph Nenning :
> But still: method:add works while !add does not.

If you could prepare a small demo app, I'd like investigate that.


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Re: Re: Re: Url rewriting of .action to .jsp

[Christoph Nenning]

> >> > Yeah, I like the idea of strict-DMI. Right now I could not get it
> > working
> >> > with the convention pulgin, can investigate next week.
> >>
> >> That's why I want to have programmable configuration in XWork and 
then
> >> XML or Convention configuration via plugins - there strict path how 
to
> >> add new configuration option, like DMI strict mode.
> >>
> >> > And I just realized that using "method:foo" parameter names works
> >> > independent of DMI.
> >>
> >> Strange, what ActionMapper do you use?
> >>
> >
> > In the app I tested with I have 2.3.15.1 and default ActionMapper 
(nothing
> > configured). strict-DMI was not explicitly enabled.
> >
> > I just added "allowed-methods" to one action. Afterwards I could not
> > invoke methods via URL (gave me method-not-allowed).
> > But a form with "method:add" did still work (while foo!add.action did
> > not).
> >
> >
> > When I try to enable strict DMI like this:
> >
> > 
> >
> > I get an exception at app start:
> > org.xml.sax.SAXParseException: Attribute "strict-method-invocation" 
must
> > be declared for element type "package".
> 
> Change DTD in the header
> 
> 

Oh, yes, that was quite obvious.

But still: method:add works while !add does not.



Regards,
Christoph

This Email was scanned by Sophos Anti Virus

Re: Re: Re: Url rewriting of .action to .jsp

[Lukasz Lenart]

2013/9/24 Christoph Nenning :
>> > Yeah, I like the idea of strict-DMI. Right now I could not get it
> working
>> > with the convention pulgin, can investigate next week.
>>
>> That's why I want to have programmable configuration in XWork and then
>> XML or Convention configuration via plugins - there strict path how to
>> add new configuration option, like DMI strict mode.
>>
>> > And I just realized that using "method:foo" parameter names works
>> > independent of DMI.
>>
>> Strange, what ActionMapper do you use?
>>
>
> In the app I tested with I have 2.3.15.1 and default ActionMapper (nothing
> configured). strict-DMI was not explicitly enabled.
>
> I just added "allowed-methods" to one action. Afterwards I could not
> invoke methods via URL (gave me method-not-allowed).
> But a form with "method:add" did still work (while foo!add.action did
> not).
>
>
> When I try to enable strict DMI like this:
>
> 
>
> I get an exception at app start:
> org.xml.sax.SAXParseException: Attribute "strict-method-invocation" must
> be declared for element type "package".

Change DTD in the header


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Antwort: Re: Re: Url rewriting of .action to .jsp

[Christoph Nenning]

> > Yeah, I like the idea of strict-DMI. Right now I could not get it 
working
> > with the convention pulgin, can investigate next week.
> 
> That's why I want to have programmable configuration in XWork and then
> XML or Convention configuration via plugins - there strict path how to
> add new configuration option, like DMI strict mode.
> 
> > And I just realized that using "method:foo" parameter names works
> > independent of DMI.
> 
> Strange, what ActionMapper do you use?
> 

In the app I tested with I have 2.3.15.1 and default ActionMapper (nothing 
configured). strict-DMI was not explicitly enabled.

I just added "allowed-methods" to one action. Afterwards I could not 
invoke methods via URL (gave me method-not-allowed).
But a form with "method:add" did still work (while foo!add.action did 
not).


When I try to enable strict DMI like this:



I get an exception at app start:
org.xml.sax.SAXParseException: Attribute "strict-method-invocation" must 
be declared for element type "package".




In another app, which is older and bigger, we do not use "method:" but 
bang-URLs for POST Requests. That is the one that did not work and needs 
more investigation.


Regards,
Christoph

This Email was scanned by Sophos Anti Virus

Re: Re: Url rewriting of .action to .jsp

[Lukasz Lenart]

2013/9/24 Christoph Nenning :
> Yeah, I like the idea of strict-DMI. Right now I could not get it working
> with the convention pulgin, can investigate next week.

That's why I want to have programmable configuration in XWork and then
XML or Convention configuration via plugins - there strict path how to
add new configuration option, like DMI strict mode.

> And I just realized that using "method:foo" parameter names works
> independent of DMI.

Strange, what ActionMapper do you use?


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Antwort: Re: Url rewriting of .action to .jsp

[Christoph Nenning]

> >> Hi all,
> >> I'm using DMI to call "input" method extensively,
> >> almost in every Edit*Action.
> >> I call it with ParamsPrepareParams stack.
> >>
> >> I fully understand that allowing DMI is a security problem.
> >> But maybe some kind of balance could be achevied.
> >> White listing with annotations would not be bad for me
> >> also maybe letting call only input (or similar) method by default
> >> would not cause to much of a security problem?
> >>
> >> I'm not saying that i will drop S2
> >> if DMI will be disabled,
> >> but sure it will make me rewrite all my edit actions.
> >
> > There is "strict dmi" [1] but I doubt that anybody is using it ;-)
> > Anyway, doing some improvement in that area is better than removing
> > DMI at all ;-)
> > Maybe we should switch to strict dmi by default - e.g "execute, input,
> > edit, submit, form" are the only allowed methods to be called via DMI.
> > And then remove DMI on/off switch at all (DMI will be always enabled).
> >
> > [1] http://struts.apache.org/release/2.3.x/docs/action-
> configuration.html#ActionConfiguration-DynamicMethodInvocation
> >
> 
> Strict DMI looks good.
> I didn't know it.
> Thats like white-listing methods.
> I will try it out and report.
> 
> Thanks.
> 
> 

Yeah, I like the idea of strict-DMI. Right now I could not get it working 
with the convention pulgin, can investigate next week.

And I just realized that using "method:foo" parameter names works 
independent of DMI.



Regards,
Christoph

This Email was scanned by Sophos Anti Virus

Re: Url rewriting of .action to .jsp

[Volker Krebs]

Am 23.09.2013 20:32, schrieb Lukasz Lenart:

2013/9/23 Paweł Wielgus :

Hi all,
I'm using DMI to call "input" method extensively,
almost in every Edit*Action.
I call it with ParamsPrepareParams stack.

I fully understand that allowing DMI is a security problem.
But maybe some kind of balance could be achevied.
White listing with annotations would not be bad for me
also maybe letting call only input (or similar) method by default
would not cause to much of a security problem?

I'm not saying that i will drop S2
if DMI will be disabled,
but sure it will make me rewrite all my edit actions.


There is "strict dmi" [1] but I doubt that anybody is using it ;-)
Anyway, doing some improvement in that area is better than removing
DMI at all ;-)
Maybe we should switch to strict dmi by default - e.g "execute, input,
edit, submit, form" are the only allowed methods to be called via DMI.
And then remove DMI on/off switch at all (DMI will be always enabled).

[1] 
http://struts.apache.org/release/2.3.x/docs/action-configuration.html#ActionConfiguration-DynamicMethodInvocation



Strict DMI looks good.
I didn't know it.
Thats like white-listing methods.
I will try it out and report.

Thanks.

-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Re: Url rewriting of .action to .jsp

[Lukasz Lenart]

2013/9/24 Paweł Wielgus :
> One more side note,
> if i understand it wright,
> in my case (Edit input and execute methods)
> wildcard mapping would be better from framework perspective
> but it needs to be wriitten in xml configuration.
>
> Whereas DMI do not require me to write any xml,
> but is not first class citizen in terms of framework.

Yes, that's true.


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Re: Url rewriting of .action to .jsp

[Paweł Wielgus]

One more side note,
if i understand it wright,
in my case (Edit input and execute methods)
wildcard mapping would be better from framework perspective
but it needs to be wriitten in xml configuration.

Whereas DMI do not require me to write any xml,
but is not first class citizen in terms of framework.

Best greetings,
Paweł Wielgus.




2013/9/24 Paweł Wielgus :
> Hi Lukasz,
> i see no problem for me in solution described by You.
> Off course i'm no security expert here.
>
> Best greetings,
> Paweł Wielgus.
>
>
> 2013/9/23 Lukasz Lenart :
>> 2013/9/23 Paweł Wielgus :
>>> Hi all,
>>> I'm using DMI to call "input" method extensively,
>>> almost in every Edit*Action.
>>> I call it with ParamsPrepareParams stack.
>>>
>>> I fully understand that allowing DMI is a security problem.
>>> But maybe some kind of balance could be achevied.
>>> White listing with annotations would not be bad for me
>>> also maybe letting call only input (or similar) method by default
>>> would not cause to much of a security problem?
>>>
>>> I'm not saying that i will drop S2
>>> if DMI will be disabled,
>>> but sure it will make me rewrite all my edit actions.
>>
>> There is "strict dmi" [1] but I doubt that anybody is using it ;-)
>> Anyway, doing some improvement in that area is better than removing
>> DMI at all ;-)
>> Maybe we should switch to strict dmi by default - e.g "execute, input,
>> edit, submit, form" are the only allowed methods to be called via DMI.
>> And then remove DMI on/off switch at all (DMI will be always enabled).
>>
>> [1] 
>> http://struts.apache.org/release/2.3.x/docs/action-configuration.html#ActionConfiguration-DynamicMethodInvocation
>>
>>
>> Regards
>> --
>> Łukasz
>> + 48 606 323 122 http://www.lenart.org.pl/
>>
>> -
>> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
>> For additional commands, e-mail: user-h...@struts.apache.org
>>

-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Re: Url rewriting of .action to .jsp

[Paweł Wielgus]

Hi Lukasz,
i see no problem for me in solution described by You.
Off course i'm no security expert here.

Best greetings,
Paweł Wielgus.


2013/9/23 Lukasz Lenart :
> 2013/9/23 Paweł Wielgus :
>> Hi all,
>> I'm using DMI to call "input" method extensively,
>> almost in every Edit*Action.
>> I call it with ParamsPrepareParams stack.
>>
>> I fully understand that allowing DMI is a security problem.
>> But maybe some kind of balance could be achevied.
>> White listing with annotations would not be bad for me
>> also maybe letting call only input (or similar) method by default
>> would not cause to much of a security problem?
>>
>> I'm not saying that i will drop S2
>> if DMI will be disabled,
>> but sure it will make me rewrite all my edit actions.
>
> There is "strict dmi" [1] but I doubt that anybody is using it ;-)
> Anyway, doing some improvement in that area is better than removing
> DMI at all ;-)
> Maybe we should switch to strict dmi by default - e.g "execute, input,
> edit, submit, form" are the only allowed methods to be called via DMI.
> And then remove DMI on/off switch at all (DMI will be always enabled).
>
> [1] 
> http://struts.apache.org/release/2.3.x/docs/action-configuration.html#ActionConfiguration-DynamicMethodInvocation
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> -
> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
> For additional commands, e-mail: user-h...@struts.apache.org
>

-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Re: Url rewriting of .action to .jsp

[Lukasz Lenart]

2013/9/23 Volker Krebs :
> Am 23.09.2013 11:05, schrieb Christoph Nenning:
>>>
>>>
>>> Just a hint: DMI can be dangerous and we think about removing it.
>>>
>> That would force us to do heavy refactorings in all our applications.
>
>
> Removing DMI completely would break a lot of applications.
> How about white-listing methods ?
>
> At the moment we have a lot of trouble updating all our applications.
> When DMI would be removed, we were forced to drop struts2 and re-implement.

That's why I have posted my doubts - we consider so we need community's opinion


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Re: Url rewriting of .action to .jsp

[Lukasz Lenart]

2013/9/23 Paweł Wielgus :
> Hi all,
> I'm using DMI to call "input" method extensively,
> almost in every Edit*Action.
> I call it with ParamsPrepareParams stack.
>
> I fully understand that allowing DMI is a security problem.
> But maybe some kind of balance could be achevied.
> White listing with annotations would not be bad for me
> also maybe letting call only input (or similar) method by default
> would not cause to much of a security problem?
>
> I'm not saying that i will drop S2
> if DMI will be disabled,
> but sure it will make me rewrite all my edit actions.

There is "strict dmi" [1] but I doubt that anybody is using it ;-)
Anyway, doing some improvement in that area is better than removing
DMI at all ;-)
Maybe we should switch to strict dmi by default - e.g "execute, input,
edit, submit, form" are the only allowed methods to be called via DMI.
And then remove DMI on/off switch at all (DMI will be always enabled).

[1] 
http://struts.apache.org/release/2.3.x/docs/action-configuration.html#ActionConfiguration-DynamicMethodInvocation


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Re: Url rewriting of .action to .jsp

[Paweł Wielgus]

Hi all,
I'm using DMI to call "input" method extensively,
almost in every Edit*Action.
I call it with ParamsPrepareParams stack.

I fully understand that allowing DMI is a security problem.
But maybe some kind of balance could be achevied.
White listing with annotations would not be bad for me
also maybe letting call only input (or similar) method by default
would not cause to much of a security problem?

I'm not saying that i will drop S2
if DMI will be disabled,
but sure it will make me rewrite all my edit actions.

Best greetings,
Paweł Wielgus.



2013/9/23 Volker Krebs :
> Am 23.09.2013 11:05, schrieb Christoph Nenning:
>>>
>>>
>>> Just a hint: DMI can be dangerous and we think about removing it.
>>>
>> That would force us to do heavy refactorings in all our applications.
>
>
> Removing DMI completely would break a lot of applications.
> How about white-listing methods ?
>
> At the moment we have a lot of trouble updating all our applications.
> When DMI would be removed, we were forced to drop struts2 and re-implement.
>
> Greetings
>
> -
> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
> For additional commands, e-mail: user-h...@struts.apache.org
>

-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Re: Url rewriting of .action to .jsp

[Volker Krebs]

Am 23.09.2013 11:05, schrieb Christoph Nenning:


Just a hint: DMI can be dangerous and we think about removing it.


That would force us to do heavy refactorings in all our applications.


Removing DMI completely would break a lot of applications.
How about white-listing methods ?

At the moment we have a lot of trouble updating all our applications.
When DMI would be removed, we were forced to drop struts2 and re-implement.

Greetings

-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Re: Url rewriting of .action to .jsp

[Christoph Nenning]

> 
> Just a hint: DMI can be dangerous and we think about removing it.
> 

That would force us to do heavy refactorings in all our applications.

This Email was scanned by Sophos Anti Virus

Re: Url rewriting of .action to .jsp

[Lukasz Lenart]

Just a hint: DMI can be dangerous and we think about removing it.

2013/9/23 Christoph Nenning :
> It seems a little late to join this discussion, but anyway here is what I
> think.
>
>
> Per default the framework shows validation errors for simple GET requests.
>
> The easiest way to work around that is to add "!input" to the url, like
> this:
>
> login!input.action
>
> You can bookmark that and generate links to the page like that.
>
>
> But I consider that rather ugly.
>
>
> The solution proposed by Lukasz is to use 2 actions: one for GET requests
> and another one for POST requests. I didn't think of that before.
>
>
>
> Here is what we usually do:
> - action.execute() is used for displaying the page (GET requests)
> - it returns INPUT (as it is the default for validation errors)
> - the INPUT result is mapped to a tile
> - enable DMI
> - for POST requests the actions provide other methods like
> login()/save()/create()
> - those methods return a result name like "redisplay" which is mapped to a
> actionRedirect result (redirect after POST)
> - to invoke the other action methods we use parameter names prefixed with
> "method:"
>
> That way we get nice URLs for GET requests and pages are shown without
> validation errors per default. And we can handle the complete page in one
> action class.
>
>
> An issue that arises is to properly initialize actions. If validation
> errors are present execute() is not invoked, so we use Prepareable to load
> data we need to display (or init lists used for s and stuff like
> that). But we have to take care that we don't override user input with DB
> content in prepare(), so some initializtaion is done in prepare() and some
> is done in execute().
>
> To avoid that we use AJAX validation which makes actions much simpler.
>
>
>
> Regards,
> Christoph
>
>
>
>
>>
>> "You cannot forward to actions"
>>
>> Thanks, that was the idea that was missing from my understanding.
>>
>> Got it working the way I wanted in a minute :)
>>
>> Many thanks - appreciated :)
>> Serdyn du Toit
>>
>>
>>
>> On Mon, Sep 23, 2013 at 8:47 AM, Lukasz Lenart
> wrote:
>>
>> > 2013/9/22 Serdyn du Toit :
>> > > What I have now is as follows:
>> > >  extends="default">
>> > > 
>> > > 
>> > > /admin/login/login.jsp
>> > > 
>> > > > > > class="com.d6.admin.login.AdminUserLoginAction">
>> > >  name="input">/admin/login/login-form.htm
>> > > > > name="success">/admin/dashboard/dashboard.htm
>> > > 
>> > > 
>> > >
>> > > The following part is just problematic - I'm struggling to find
> these
>> > > resources.  My browser tells me "the requested resources is not
>> > available",
>> > > but when I hit the actions directly everything works 100%
>> >
>> > You cannot forward to actions - that what you do right now: > > name="input"> - changing extension to .htm doesn't change action
>> > in a file. You can forward only to static resources (files), actions
>> > are logical resources.
>> >
>> > Remove "struts.action.extension" - stick with default.
>> >
>> > Check out struts2-blank application and see how it is solved there -
>> > example.xml, Login action class, Login.jsp and Login-validation.xml
>> >
>> > https://svn.apache.org/repos/asf/struts/struts2/trunk/apps/blank/
>> >
>> >
>> > Regards
>> > --
>> > Łukasz
>> > + 48 606 323 122 http://www.lenart.org.pl/
>> >
>> > -
>> > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
>> > For additional commands, e-mail: user-h...@struts.apache.org
>> >
>> >
>
> This Email was scanned by Sophos Anti Virus

-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Re: Url rewriting of .action to .jsp

[Christoph Nenning]

It seems a little late to join this discussion, but anyway here is what I 
think.


Per default the framework shows validation errors for simple GET requests.

The easiest way to work around that is to add "!input" to the url, like 
this:

login!input.action

You can bookmark that and generate links to the page like that.


But I consider that rather ugly.


The solution proposed by Lukasz is to use 2 actions: one for GET requests 
and another one for POST requests. I didn't think of that before.



Here is what we usually do:
- action.execute() is used for displaying the page (GET requests)
- it returns INPUT (as it is the default for validation errors)
- the INPUT result is mapped to a tile
- enable DMI
- for POST requests the actions provide other methods like 
login()/save()/create()
- those methods return a result name like "redisplay" which is mapped to a 
actionRedirect result (redirect after POST)
- to invoke the other action methods we use parameter names prefixed with 
"method:"

That way we get nice URLs for GET requests and pages are shown without 
validation errors per default. And we can handle the complete page in one 
action class.


An issue that arises is to properly initialize actions. If validation 
errors are present execute() is not invoked, so we use Prepareable to load 
data we need to display (or init lists used for s and stuff like 
that). But we have to take care that we don't override user input with DB 
content in prepare(), so some initializtaion is done in prepare() and some 
is done in execute().

To avoid that we use AJAX validation which makes actions much simpler.



Regards,
Christoph




> 
> "You cannot forward to actions"
> 
> Thanks, that was the idea that was missing from my understanding.
> 
> Got it working the way I wanted in a minute :)
> 
> Many thanks - appreciated :)
> Serdyn du Toit
> 
> 
> 
> On Mon, Sep 23, 2013 at 8:47 AM, Lukasz Lenart 
wrote:
> 
> > 2013/9/22 Serdyn du Toit :
> > > What I have now is as follows:
> > > 
> > > 
> > > 
> > > /admin/login/login.jsp
> > > 
> > >  > > class="com.d6.admin.login.AdminUserLoginAction">
> > > /admin/login/login-form.htm
> > >  > name="success">/admin/dashboard/dashboard.htm
> > > 
> > > 
> > >
> > > The following part is just problematic - I'm struggling to find 
these
> > > resources.  My browser tells me "the requested resources is not
> > available",
> > > but when I hit the actions directly everything works 100%
> >
> > You cannot forward to actions - that what you do right now:  > name="input"> - changing extension to .htm doesn't change action
> > in a file. You can forward only to static resources (files), actions
> > are logical resources.
> >
> > Remove "struts.action.extension" - stick with default.
> >
> > Check out struts2-blank application and see how it is solved there -
> > example.xml, Login action class, Login.jsp and Login-validation.xml
> >
> > https://svn.apache.org/repos/asf/struts/struts2/trunk/apps/blank/
> >
> >
> > Regards
> > --
> > Łukasz
> > + 48 606 323 122 http://www.lenart.org.pl/
> >
> > -
> > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
> > For additional commands, e-mail: user-h...@struts.apache.org
> >
> >

This Email was scanned by Sophos Anti Virus

Re: Url rewriting of .action to .jsp

[Serdyn du Toit]

"You cannot forward to actions"

Thanks, that was the idea that was missing from my understanding.

Got it working the way I wanted in a minute :)

Many thanks - appreciated :)
Serdyn du Toit



On Mon, Sep 23, 2013 at 8:47 AM, Lukasz Lenart wrote:

> 2013/9/22 Serdyn du Toit :
> > What I have now is as follows:
> > 
> > 
> > 
> > /admin/login/login.jsp
> > 
> >  > class="com.d6.admin.login.AdminUserLoginAction">
> > /admin/login/login-form.htm
> >  name="success">/admin/dashboard/dashboard.htm
> > 
> > 
> >
> > The following part is just problematic - I'm struggling to find these
> > resources.  My browser tells me "the requested resources is not
> available",
> > but when I hit the actions directly everything works 100%
>
> You cannot forward to actions - that what you do right now:  name="input"> - changing extension to .htm doesn't change action
> in a file. You can forward only to static resources (files), actions
> are logical resources.
>
> Remove "struts.action.extension" - stick with default.
>
> Check out struts2-blank application and see how it is solved there -
> example.xml, Login action class, Login.jsp and Login-validation.xml
>
> https://svn.apache.org/repos/asf/struts/struts2/trunk/apps/blank/
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> -
> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
> For additional commands, e-mail: user-h...@struts.apache.org
>
>

Re: Url rewriting of .action to .jsp

[Lukasz Lenart]

2013/9/22 Serdyn du Toit :
> What I have now is as follows:
> 
> 
> 
> /admin/login/login.jsp
> 
>  class="com.d6.admin.login.AdminUserLoginAction">
> /admin/login/login-form.htm
> /admin/dashboard/dashboard.htm
> 
> 
>
> The following part is just problematic - I'm struggling to find these
> resources.  My browser tells me "the requested resources is not available",
> but when I hit the actions directly everything works 100%

You cannot forward to actions - that what you do right now:  - changing extension to .htm doesn't change action
in a file. You can forward only to static resources (files), actions
are logical resources.

Remove "struts.action.extension" - stick with default.

Check out struts2-blank application and see how it is solved there -
example.xml, Login action class, Login.jsp and Login-validation.xml

https://svn.apache.org/repos/asf/struts/struts2/trunk/apps/blank/


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Re: Url rewriting of .action to .jsp

[Serdyn du Toit]

Okay, I got the second result working:
/admin/dashboard/dashboard.htm

Now, just the first one I'm still having problems with as I don't want to
redirect
/admin/login/login-form.htm



On Sun, Sep 22, 2013 at 11:16 PM, Serdyn du Toit  wrote:

> Thanks guys,
>
> Just having a bit of trouble getting it 100% - sorry for the trouble (my
> first Struts project)
>
> What I have now is as follows:
> 
> 
> 
> /admin/login/login.jsp
> 
>  class="com.d6.admin.login.AdminUserLoginAction">
> /admin/login/login-form.htm
> /admin/dashboard/dashboard.htm
> 
> 
>
> The following part is just problematic - I'm struggling to find these
> resources.  My browser tells me "the requested resources is not available",
> but when I hit the actions directly everything works 100%
> /admin/login/login-form.htm
> /admin/dashboard/dashboard.htm
>
> Using  and having
> tried to define them in the xml file without the extension as well...
>  (minor point, more worried now about the resources not being found)
>
> Regards,
> Serdyn du Toit
>
>
>
> On Sun, Sep 22, 2013 at 6:56 PM, Lukasz Lenart wrote:
>
>> You should never ever allow to access JSPs directly! Thus can be
>> potential security risk!
>>
>> What you want to achieve are two actions:
>> - login-form.action to display login form
>> - login.action to submit login form to and perform validation/user login
>>
>> Instead thinking about JSPs behind, think about actions.
>>
>>
>> Regards
>> --
>> Łukasz
>> + 48 606 323 122 http://www.lenart.org.pl/
>>
>> 2013/9/22 Serdyn du Toit :
>> > Hi,
>> >
>> > I have the following Struts action defined in Xml:
>> > 
>> > 
>> >
>> > > > class="com.d6.adminweb.login.AdminUserLoginAction">
>> > /admin/login/login.jsp
>> > > > type="redirect">/admin/dashboard/frames.jsp
>> > 
>> > 
>> >
>> > When I submit the page and validation fails my browser has the following
>> > Url:
>> > http://localhost:8080/webapp/admin/login/login.action<
>> http://localhost:8080/rf-adminweb/admin/login/login.action>
>> >
>> > How can I make it display
>> > http://localhost:8080/webapp/admin/login/login.j<
>> http://localhost:8080/rf-adminweb/admin/login/login.action>
>> > sp
>> >
>> > If I never see .action in the browser I'd be happy :)
>> >
>> > I want it to be login.jsp so that someone can bookmark the page even
>> after
>> > a failed form submission.  Sure, one can bookmark login.action - but
>> then
>> > when you load the page you're going to see a lot of errors due to empty
>> > input fields (the Action's validation)
>> >
>> > Using a "redirect" worked for the second result type:
>> > > > type="redirect">/admin/dashboard/frames.jsp
>> >
>> > But in this case if I do that then my errors are no longer displayed on
>> the
>> > page (guess it gets lost when I redirect)
>> >
>> > Any suggestions appreciated :)
>>
>> -
>> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
>> For additional commands, e-mail: user-h...@struts.apache.org
>>
>>
>

Re: Url rewriting of .action to .jsp

[Serdyn du Toit]

Thanks guys,

Just having a bit of trouble getting it 100% - sorry for the trouble (my
first Struts project)

What I have now is as follows:



/admin/login/login.jsp


/admin/login/login-form.htm
/admin/dashboard/dashboard.htm



The following part is just problematic - I'm struggling to find these
resources.  My browser tells me "the requested resources is not available",
but when I hit the actions directly everything works 100%
/admin/login/login-form.htm
/admin/dashboard/dashboard.htm

Using  and having
tried to define them in the xml file without the extension as well...
 (minor point, more worried now about the resources not being found)

Regards,
Serdyn du Toit



On Sun, Sep 22, 2013 at 6:56 PM, Lukasz Lenart wrote:

> You should never ever allow to access JSPs directly! Thus can be
> potential security risk!
>
> What you want to achieve are two actions:
> - login-form.action to display login form
> - login.action to submit login form to and perform validation/user login
>
> Instead thinking about JSPs behind, think about actions.
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> 2013/9/22 Serdyn du Toit :
> > Hi,
> >
> > I have the following Struts action defined in Xml:
> > 
> > 
> >
> >  > class="com.d6.adminweb.login.AdminUserLoginAction">
> > /admin/login/login.jsp
> >  > type="redirect">/admin/dashboard/frames.jsp
> > 
> > 
> >
> > When I submit the page and validation fails my browser has the following
> > Url:
> > http://localhost:8080/webapp/admin/login/login.action<
> http://localhost:8080/rf-adminweb/admin/login/login.action>
> >
> > How can I make it display
> > http://localhost:8080/webapp/admin/login/login.j<
> http://localhost:8080/rf-adminweb/admin/login/login.action>
> > sp
> >
> > If I never see .action in the browser I'd be happy :)
> >
> > I want it to be login.jsp so that someone can bookmark the page even
> after
> > a failed form submission.  Sure, one can bookmark login.action - but then
> > when you load the page you're going to see a lot of errors due to empty
> > input fields (the Action's validation)
> >
> > Using a "redirect" worked for the second result type:
> >  > type="redirect">/admin/dashboard/frames.jsp
> >
> > But in this case if I do that then my errors are no longer displayed on
> the
> > page (guess it gets lost when I redirect)
> >
> > Any suggestions appreciated :)
>
> -
> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
> For additional commands, e-mail: user-h...@struts.apache.org
>
>

Re: Url rewriting of .action to .jsp

[Lukasz Lenart]

You should never ever allow to access JSPs directly! Thus can be
potential security risk!

What you want to achieve are two actions:
- login-form.action to display login form
- login.action to submit login form to and perform validation/user login

Instead thinking about JSPs behind, think about actions.


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

2013/9/22 Serdyn du Toit :
> Hi,
>
> I have the following Struts action defined in Xml:
> 
> 
>
>  class="com.d6.adminweb.login.AdminUserLoginAction">
> /admin/login/login.jsp
>  type="redirect">/admin/dashboard/frames.jsp
> 
> 
>
> When I submit the page and validation fails my browser has the following
> Url:
> http://localhost:8080/webapp/admin/login/login.action
>
> How can I make it display
> http://localhost:8080/webapp/admin/login/login.j
> sp
>
> If I never see .action in the browser I'd be happy :)
>
> I want it to be login.jsp so that someone can bookmark the page even after
> a failed form submission.  Sure, one can bookmark login.action - but then
> when you load the page you're going to see a lot of errors due to empty
> input fields (the Action's validation)
>
> Using a "redirect" worked for the second result type:
>  type="redirect">/admin/dashboard/frames.jsp
>
> But in this case if I do that then my errors are no longer displayed on the
> page (guess it gets lost when I redirect)
>
> Any suggestions appreciated :)

-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Re: Url rewriting of .action to .jsp

[Chris Pratt]

That's because you are submitting that action.  If that's not what you
intended, I don't understand what you are trying to achieve.  The setting I
suggested allows you to rename the .action url extension to .jsp (or .html).
  (*Chris*)


On Sun, Sep 22, 2013 at 1:30 AM, Serdyn du Toit  wrote:

> Hi Chris,
>
> Not exactly what I'm looking for,
>
> If I now type:
> http://localhost:8080/rf-adminweb/admin/login/login.jsp
>
> Then it thinks I'm submitting the form - so my form validation errors get
> displayed.
> (ie it thinks I'm submitting the form:
> http://localhost:8080/rf-adminweb/admin/login/login.
> action)
>
> Is there something else I need to add to the config as well?
>
> Sorry, I'm a bit new to Struts 2 so my configuration isn't yet 100% the
> way I would like it - so there might be something in addition to that
> property I might have missed.
>
> Don't think its going to help, but my struts.xml:
> 
> 
> 
> 
> 
> 
>  
> 
> 
> 
> 
>
> 

Re: Url rewriting of .action to .jsp

[Serdyn du Toit]

Hi Chris,

Not exactly what I'm looking for,

If I now type:
http://localhost:8080/rf-adminweb/admin/login/login.jsp

Then it thinks I'm submitting the form - so my form validation errors get
displayed.
(ie it thinks I'm submitting the form:
http://localhost:8080/rf-adminweb/admin/login/login.
action)

Is there something else I need to add to the config as well?

Sorry, I'm a bit new to Struts 2 so my configuration isn't yet 100% the way
I would like it - so there might be something in addition to that property
I might have missed.

Don't think its going to help, but my struts.xml:


























/admin/login/sessionExpired.jsp




Kind regards,
Serdyn du Toit


On Sun, Sep 22, 2013 at 9:36 AM, Chris Pratt wrote:

> Put the following in your struts.xml configuration file:
>
>  
>
> I actually prefer:
>
>   
>
> since it hides the underlying technology just a bit better and makes a tiny
> bit harder for someone to guess how to hack it.  It's not high security,
> but every little bit helps.
>   (*Chris*)
>
>
>
> On Sat, Sep 21, 2013 at 10:44 PM, Serdyn du Toit 
> wrote:
>
> > Hi,
> >
> > I have the following Struts action defined in Xml:
> > 
> > 
> >
> >  > class="com.d6.adminweb.login.AdminUserLoginAction">
> > /admin/login/login.jsp
> >  > type="redirect">/admin/dashboard/frames.jsp
> > 
> > 
> >
> > When I submit the page and validation fails my browser has the following
> > Url:
> > http://localhost:8080/webapp/admin/login/login.action<
> > http://localhost:8080/rf-adminweb/admin/login/login.action>
> >
> > How can I make it display
> > http://localhost:8080/webapp/admin/login/login.j<
> > http://localhost:8080/rf-adminweb/admin/login/login.action>
> > sp
> >
> > If I never see .action in the browser I'd be happy :)
> >
> > I want it to be login.jsp so that someone can bookmark the page even
> after
> > a failed form submission.  Sure, one can bookmark login.action - but then
> > when you load the page you're going to see a lot of errors due to empty
> > input fields (the Action's validation)
> >
> > Using a "redirect" worked for the second result type:
> >  > type="redirect">/admin/dashboard/frames.jsp
> >
> > But in this case if I do that then my errors are no longer displayed on
> the
> > page (guess it gets lost when I redirect)
> >
> > Any suggestions appreciated :)
> >
>

Re: Url rewriting of .action to .jsp

[Chris Pratt]

Put the following in your struts.xml configuration file:

 

I actually prefer:

  

since it hides the underlying technology just a bit better and makes a tiny
bit harder for someone to guess how to hack it.  It's not high security,
but every little bit helps.
  (*Chris*)



On Sat, Sep 21, 2013 at 10:44 PM, Serdyn du Toit  wrote:

> Hi,
>
> I have the following Struts action defined in Xml:
> 
> 
>
>  class="com.d6.adminweb.login.AdminUserLoginAction">
> /admin/login/login.jsp
>  type="redirect">/admin/dashboard/frames.jsp
> 
> 
>
> When I submit the page and validation fails my browser has the following
> Url:
> http://localhost:8080/webapp/admin/login/login.action<
> http://localhost:8080/rf-adminweb/admin/login/login.action>
>
> How can I make it display
> http://localhost:8080/webapp/admin/login/login.j<
> http://localhost:8080/rf-adminweb/admin/login/login.action>
> sp
>
> If I never see .action in the browser I'd be happy :)
>
> I want it to be login.jsp so that someone can bookmark the page even after
> a failed form submission.  Sure, one can bookmark login.action - but then
> when you load the page you're going to see a lot of errors due to empty
> input fields (the Action's validation)
>
> Using a "redirect" worked for the second result type:
>  type="redirect">/admin/dashboard/frames.jsp
>
> But in this case if I do that then my errors are no longer displayed on the
> page (guess it gets lost when I redirect)
>
> Any suggestions appreciated :)
>

Url rewriting of .action to .jsp

[Serdyn du Toit]

Hi,

I have the following Struts action defined in Xml:




/admin/login/login.jsp
/admin/dashboard/frames.jsp



When I submit the page and validation fails my browser has the following
Url:
http://localhost:8080/webapp/admin/login/login.action

How can I make it display
http://localhost:8080/webapp/admin/login/login.j
sp

If I never see .action in the browser I'd be happy :)

I want it to be login.jsp so that someone can bookmark the page even after
a failed form submission.  Sure, one can bookmark login.action - but then
when you load the page you're going to see a lot of errors due to empty
input fields (the Action's validation)

Using a "redirect" worked for the second result type:
/admin/dashboard/frames.jsp

But in this case if I do that then my errors are no longer displayed on the
page (guess it gets lost when I redirect)

Any suggestions appreciated :)

Re: Struts + redirect=true + Apache Proxy Url Rewriting Problem

[Miguel Cohnen]

It worked like a charm! You just need to add a special connector that handle
proxy requests like explained in the link below.

Thank you very very much!

On Thu, Aug 14, 2008 at 2:08 PM, duschhaube <[EMAIL PROTECTED]> wrote:

> Hi,
>
> I think you can handle this by the tomcat configuration.
>
> see this link for instructions:
> http://tomcat.apache.org/tomcat-6.0-doc/proxy-howto.html
>
> but i have not test it myself.
>
>
> Miguel Cohnen schrieb:
>
>  Hi Everybody,
>>
>> First I wanted to say hello to everybody here, as this is my first mail in
>> the list. I also wanted to apologize if my english is not good enough, but
>> i'll do my best!
>>
>> This is the problem I am having:
>>
>> I am building an application using tomcat 5.5 and struts. Let's say that
>> the
>> base url form my application is http://myserver:8080/myapp. I have to use
>> an
>> Apache Proxy in front of my Tomcat Server (because of different reasons),
>> so
>> that my application can be reached using http://apacheserver/myapp(default
>> port 80). I use such a rule in my Apache configuration fro rewriting urls:
>> RewriteRule ^/myapp(.*) \http://myserver:8080/myapp$1 [P]
>>
>> It works perfect so that i can navigate through my application using
>> http://apacheserver/myapp. But if using 'redirect=true' in one of my
>> mappings,eg. after a form processing ends, the browser's url changes to
>> http://myserver:8080/myapp ...
>>
>> How can i get rid of this? I need to keep on navigating through the proxy,
>> but I also would like to use redirect=true...
>>
>> Thank you alot, and i hope someone can help me out. Below you can find
>> some
>> info about my environment:
>>
>> Apache Web Server 2.0
>> Tomcat 5.5
>> Struts 1.2.8
>> Java 5
>>
>>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
Un saludo,
Miguel Cohnen de la Cámara

Re: Struts + redirect=true + Apache Proxy Url Rewriting Problem

[duschhaube]

Hi,

I think you can handle this by the tomcat configuration.

see this link for instructions:
http://tomcat.apache.org/tomcat-6.0-doc/proxy-howto.html

but i have not test it myself.


Miguel Cohnen schrieb:

Hi Everybody,

First I wanted to say hello to everybody here, as this is my first mail in
the list. I also wanted to apologize if my english is not good enough, but
i'll do my best!

This is the problem I am having:

I am building an application using tomcat 5.5 and struts. Let's say that the
base url form my application is http://myserver:8080/myapp. I have to use an
Apache Proxy in front of my Tomcat Server (because of different reasons), so
that my application can be reached using http://apacheserver/myapp (default
port 80). I use such a rule in my Apache configuration fro rewriting urls:
RewriteRule ^/myapp(.*) \http://myserver:8080/myapp$1 [P]

It works perfect so that i can navigate through my application using
http://apacheserver/myapp. But if using 'redirect=true' in one of my
mappings,eg. after a form processing ends, the browser's url changes to
http://myserver:8080/myapp ...

How can i get rid of this? I need to keep on navigating through the proxy,
but I also would like to use redirect=true...

Thank you alot, and i hope someone can help me out. Below you can find some
info about my environment:

Apache Web Server 2.0
Tomcat 5.5
Struts 1.2.8
Java 5




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Struts + redirect=true + Apache Proxy Url Rewriting Problem

[Miguel Cohnen]

Hi Everybody,

First I wanted to say hello to everybody here, as this is my first mail in
the list. I also wanted to apologize if my english is not good enough, but
i'll do my best!

This is the problem I am having:

I am building an application using tomcat 5.5 and struts. Let's say that the
base url form my application is http://myserver:8080/myapp. I have to use an
Apache Proxy in front of my Tomcat Server (because of different reasons), so
that my application can be reached using http://apacheserver/myapp (default
port 80). I use such a rule in my Apache configuration fro rewriting urls:
RewriteRule ^/myapp(.*) \http://myserver:8080/myapp$1 [P]

It works perfect so that i can navigate through my application using
http://apacheserver/myapp. But if using 'redirect=true' in one of my
mappings,eg. after a form processing ends, the browser's url changes to
http://myserver:8080/myapp ...

How can i get rid of this? I need to keep on navigating through the proxy,
but I also would like to use redirect=true...

Thank you alot, and i hope someone can help me out. Below you can find some
info about my environment:

Apache Web Server 2.0
Tomcat 5.5
Struts 1.2.8
Java 5

-- 
Un saludo,
Miguel Cohnen de la Cámara

Re: Problem with URL-Rewriting in WebSphere

[Roberto Flores]

I'm using version 6.0.0.1.

I'm sorry, I don't know how to do that. Can you point me to some manual or
tutorial on these?

2007/1/17, Gary VanMatre <[EMAIL PROTECTED]>:


>From: "Roberto Flores" <[EMAIL PROTECTED]>
>
> If I manually take out the ;jsessionid=132mksvl213:-1 from the url the
> action is found (but the session is lost of course).
>
> There's something wrong with the URL parser but I don't know what it is
or
> if it's a struts or websphere problem/
>

You must be going thru a webserver that dispatches to your application
server?

If so, I'd try republishing the config file the webserver plugin uses.  In
WAS 6 the server will push the config to the webserver but in WAS 5 you have
to copy it to the server depending on the setup.

If you are going directly to the application server, it might be a problem
with the virtual host mappings.  What port are you using (
http://myhost:9080/xxx/xxx.do)?   What version of WAS are you using?

Gary


> 2007/1/15, Gary VanMatre :
> >
> > >From: "Roberto Flores"
> > >
> > > Greetings,
> > >
> > > I can't use cookies since this app is for cellphones. On Tomcat
there's
> > no
> > > problem, but in WebSphere enabling only url-rewriting causes 404
errors
> > on
> > > every page transition.
> > >
> > > Upon further inspection, the jsessionid values generated by
WebSphere
> > are
> > > drastically different than the ones used by Tomcat:
> > >
> > > WebSphere (form)
> > >
...action="/mo/HT40121.do;jsessionid=XwB08FgkQm4GzTCmLGT7jU4:-1">
> > >
> >
> >
> > The last part of the jsessionid ":-1" represents the server you are
pinned
> > to if you have
> > a clustered environment. The web-server plug-in will try to send you
to
> > the same server
> > where your session was initially established.
> >
> >
> > > Tomcat (form)
> > >
...action="/mo/HT40121.do;jsessionid=CBDCF468D0874528995F835F16A2BF30
> > >
> > > Clicking the submit button returns a 404. It seems the jsessionid is
not
> > > being parsed at all.
> > >
> > > Can you tell me if this is a configuration problem in either the
Struts
> > side
> > > or WebSphere?
> > >
> >
> >
> > Do you think the 404 is because it is unable to find an action or a
JSP
> > page that the action is
> > forwarding to? My guess is that it is a relative path problem were you
> > are missing a html:base
> > tag in your header. Just a guess...
> >
> >
> >
> > > Thanks for any help.
> >
> >
> > Gary
> >

Re: Problem with URL-Rewriting in WebSphere

[Gary VanMatre]

>From: "Roberto Flores" <[EMAIL PROTECTED]> 
>
> If I manually take out the ;jsessionid=132mksvl213:-1 from the url the 
> action is found (but the session is lost of course). 
> 
> There's something wrong with the URL parser but I don't know what it is or 
> if it's a struts or websphere problem/ 
>

You must be going thru a webserver that dispatches to your application server?  

If so, I'd try republishing the config file the webserver plugin uses.  In WAS 
6 the server will push the config to the webserver but in WAS 5 you have to 
copy it to the server depending on the setup.

If you are going directly to the application server, it might be a problem with 
the virtual host mappings.  What port are you using 
(http://myhost:9080/xxx/xxx.do)?   What version of WAS are you using?

Gary

 
> 2007/1/15, Gary VanMatre : 
> > 
> > >From: "Roberto Flores" 
> > > 
> > > Greetings, 
> > > 
> > > I can't use cookies since this app is for cellphones. On Tomcat there's 
> > no 
> > > problem, but in WebSphere enabling only url-rewriting causes 404 errors 
> > on 
> > > every page transition. 
> > > 
> > > Upon further inspection, the jsessionid values generated by WebSphere 
> > are 
> > > drastically different than the ones used by Tomcat: 
> > > 
> > > WebSphere (form) 
> > > ...action="/mo/HT40121.do;jsessionid=XwB08FgkQm4GzTCmLGT7jU4:-1"> 
> > > 
> > 
> > 
> > The last part of the jsessionid ":-1" represents the server you are pinned 
> > to if you have 
> > a clustered environment. The web-server plug-in will try to send you to 
> > the same server 
> > where your session was initially established. 
> > 
> > 
> > > Tomcat (form) 
> > > ...action="/mo/HT40121.do;jsessionid=CBDCF468D0874528995F835F16A2BF30 
> > > 
> > > Clicking the submit button returns a 404. It seems the jsessionid is not 
> > > being parsed at all. 
> > > 
> > > Can you tell me if this is a configuration problem in either the Struts 
> > side 
> > > or WebSphere? 
> > > 
> > 
> > 
> > Do you think the 404 is because it is unable to find an action or a JSP 
> > page that the action is 
> > forwarding to? My guess is that it is a relative path problem were you 
> > are missing a html:base 
> > tag in your header. Just a guess... 
> > 
> > 
> > 
> > > Thanks for any help. 
> > 
> > 
> > Gary 
> > 

Re: Problem with URL-Rewriting in WebSphere

[Roberto Flores]

If I manually take out the ;jsessionid=132mksvl213:-1 from the url the
action is found (but the session is lost of course).

There's something wrong with the URL parser but I don't know what it is or
if it's a struts or websphere problem/

2007/1/15, Gary VanMatre <[EMAIL PROTECTED]>:


>From: "Roberto Flores" <[EMAIL PROTECTED]>
>
> Greetings,
>
> I can't use cookies since this app is for cellphones. On Tomcat there's
no
> problem, but in WebSphere enabling only url-rewriting causes 404 errors
on
> every page transition.
>
> Upon further inspection, the jsessionid values generated by WebSphere
are
> drastically different than the ones used by Tomcat:
>
> WebSphere (form)
> ...action="/mo/HT40121.do;jsessionid=XwB08FgkQm4GzTCmLGT7jU4:-1">
>


The last part of the jsessionid ":-1" represents the server you are pinned
to if you have
a clustered environment.  The web-server plug-in will try to send you to
the same server
where your session was initially established.


> Tomcat (form)
> ...action="/mo/HT40121.do;jsessionid=CBDCF468D0874528995F835F16A2BF30
>
> Clicking the submit button returns a 404. It seems the jsessionid is not
> being parsed at all.
>
> Can you tell me if this is a configuration problem in either the Struts
side
> or WebSphere?
>


Do you think the 404 is because it is unable to find an action or a JSP
page that the action is
forwarding to?  My guess is that it is a relative path problem were you
are missing a html:base
tag in your header.  Just a guess...



> Thanks for any help.


Gary

Re: Problem with URL-Rewriting in WebSphere

[Gary VanMatre]

>From: "Roberto Flores" <[EMAIL PROTECTED]> 
>
> Greetings, 
> 
> I can't use cookies since this app is for cellphones. On Tomcat there's no 
> problem, but in WebSphere enabling only url-rewriting causes 404 errors on 
> every page transition. 
> 
> Upon further inspection, the jsessionid values generated by WebSphere are 
> drastically different than the ones used by Tomcat: 
> 
> WebSphere (form) 
> ...action="/mo/HT40121.do;jsessionid=XwB08FgkQm4GzTCmLGT7jU4:-1"> 
> 


The last part of the jsessionid ":-1" represents the server you are pinned to 
if you have
a clustered environment.  The web-server plug-in will try to send you to the 
same server
where your session was initially established.


> Tomcat (form) 
> ...action="/mo/HT40121.do;jsessionid=CBDCF468D0874528995F835F16A2BF30 
> 
> Clicking the submit button returns a 404. It seems the jsessionid is not 
> being parsed at all. 
> 
> Can you tell me if this is a configuration problem in either the Struts side 
> or WebSphere? 
> 


Do you think the 404 is because it is unable to find an action or a JSP page 
that the action is 
forwarding to?  My guess is that it is a relative path problem were you are 
missing a html:base
tag in your header.  Just a guess...  



> Thanks for any help. 


Gary

Re: Problem with URL-Rewriting in WebSphere

[Roberto Flores]

IBM WebSphere Application Server - Express, 6.0.0.1

2007/1/16, Nuwan Chandrasoma <[EMAIL PROTECTED]>:


what is the WebShpere version you are using?

Nuwan.
- Original Message -
From: "Roberto Flores" <[EMAIL PROTECTED]>
To: 
Sent: Monday, January 15, 2007 9:44 AM
Subject: Problem with URL-Rewriting in WebSphere


> Greetings,
>
> I can't use cookies since this app is for cellphones. On Tomcat there's
no
> problem, but in WebSphere enabling only url-rewriting causes 404 errors
on
> every page transition.
>
> Upon further inspection, the jsessionid values generated by WebSphere
are
> drastically different than the ones used by Tomcat:
>
> WebSphere (form)
> ...action="/mo/HT40121.do;jsessionid=XwB08FgkQm4GzTCmLGT7jU4:-1">
>
> Tomcat (form)
> ...action="/mo/HT40121.do;jsessionid=CBDCF468D0874528995F835F16A2BF30
>
>  Clicking the submit button returns a 404. It seems the jsessionid is
not
> being parsed at all.
>
> Can you tell me if this is a configuration problem in either the Struts
> side
> or WebSphere?
>
> Thanks for any help.
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Problem with URL-Rewriting in WebSphere

[Nuwan Chandrasoma]

what is the WebShpere version you are using?

Nuwan.
- Original Message - 
From: "Roberto Flores" <[EMAIL PROTECTED]>

To: 
Sent: Monday, January 15, 2007 9:44 AM
Subject: Problem with URL-Rewriting in WebSphere



Greetings,

I can't use cookies since this app is for cellphones. On Tomcat there's no
problem, but in WebSphere enabling only url-rewriting causes 404 errors on
every page transition.

Upon further inspection, the jsessionid values generated by WebSphere are
drastically different than the ones used by Tomcat:

WebSphere (form)
...action="/mo/HT40121.do;jsessionid=XwB08FgkQm4GzTCmLGT7jU4:-1">

Tomcat (form)
...action="/mo/HT40121.do;jsessionid=CBDCF468D0874528995F835F16A2BF30

 Clicking the submit button returns a 404. It seems the jsessionid is not
being parsed at all.

Can you tell me if this is a configuration problem in either the Struts 
side

or WebSphere?

Thanks for any help.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Problem with URL-Rewriting in WebSphere

[Roberto Flores]

Greetings,

I can't use cookies since this app is for cellphones. On Tomcat there's no
problem, but in WebSphere enabling only url-rewriting causes 404 errors on
every page transition.

Upon further inspection, the jsessionid values generated by WebSphere are
drastically different than the ones used by Tomcat:

WebSphere (form)
...action="/mo/HT40121.do;jsessionid=XwB08FgkQm4GzTCmLGT7jU4:-1">

Tomcat (form)
...action="/mo/HT40121.do;jsessionid=CBDCF468D0874528995F835F16A2BF30

 Clicking the submit button returns a 404. It seems the jsessionid is not
being parsed at all.

Can you tell me if this is a configuration problem in either the Struts side
or WebSphere?

Thanks for any help.

Re: URL-Rewriting suddenly doesn't work any more

[Laurie Harper]

Andreas Hartmann wrote:

Hello Martin,

first of all, the application works fine again - and I think, the
application didn't had any problem ... see below.

Martin Gainty wrote:

Andreas-

 Set to true if you want cookies to be used
for session identifier communication if supported by the client (this
is the default). Set to false if you want to disable the use of cookies
for session identifier communication, and rely only on URL rewriting by
the application.

--so when you move to the new server and take the default you are using
cookies in lieu of URL rewrite


I took the whole installation to the new server - therefore, using of
cookies wasn't able, too.


OldServer If you are using rewrite which Apache server is handling the
re-writing and how is this implemented?


I don't use any apache server - I'm just using tomcat with nothing else.
The URL-rewriting is done automatically - I didn't do anything besides the
definition in webapps/application/META-INF/context.xml.


But I think I do know the problem meanwhile:
I started a 4 th tomcat-session on the machine, a plain tomcat
installation and run struts-blank. During tracing (with ethereal) my
"broken" application, I could see a session cookie (-> jsessionid) in the
header, sent from the browser to the server when the login-page has been
started. But there isn't sent any rewritten URL back to the client after a
successful login and no correct cookie either. After restarting the
browser and therefore the deletion of the wrong cookie, the login did work
fine again.
I think there is a problem in struts / jsp wherever with the handling of
cookies and or URL-rewriting. Somebody out there, who knows more about the
implementation of the session handling with cookies and/or URL rewriting?


That sounds like it could be a broken behaviour with how Tomcat handles 
session cookies / URL rewriting when it gets a bad session cookie. You 
might want to follow up on the Tomcat users' list; Struts doesn't get 
involved in session tracking, that's all handled by Tomcat.


L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: URL-Rewriting suddenly doesn't work any more

[Andreas Hartmann]

Hello Martin,

first of all, the application works fine again - and I think, the
application didn't had any problem ... see below.

Martin Gainty wrote:
> Andreas-
> 
>  Set to true if you want cookies to be used
> for session identifier communication if supported by the client (this
> is the default). Set to false if you want to disable the use of cookies
> for session identifier communication, and rely only on URL rewriting by
> the application.
> 
> --so when you move to the new server and take the default you are using
> cookies in lieu of URL rewrite

I took the whole installation to the new server - therefore, using of
cookies wasn't able, too.

> OldServer If you are using rewrite which Apache server is handling the
> re-writing and how is this implemented?

I don't use any apache server - I'm just using tomcat with nothing else.
The URL-rewriting is done automatically - I didn't do anything besides the
definition in webapps/application/META-INF/context.xml.


But I think I do know the problem meanwhile:
I started a 4 th tomcat-session on the machine, a plain tomcat
installation and run struts-blank. During tracing (with ethereal) my
"broken" application, I could see a session cookie (-> jsessionid) in the
header, sent from the browser to the server when the login-page has been
started. But there isn't sent any rewritten URL back to the client after a
successful login and no correct cookie either. After restarting the
browser and therefore the deletion of the wrong cookie, the login did work
fine again.
I think there is a problem in struts / jsp wherever with the handling of
cookies and or URL-rewriting. Somebody out there, who knows more about the
implementation of the session handling with cookies and/or URL rewriting?


Kind regards,
Andreas Hartmann

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: URL-Rewriting suddenly doesn't work any more

[Martin Gainty]

Andreas-

 
Set to true if you want cookies to be used for session identifier communication 
if supported by the client (this is the default). 
Set to false if you want to disable the use of cookies for session identifier 
communication, and rely only on URL rewriting by the application.

--so when you move to the new server and take the default you are using cookies 
in lieu of URL rewrite

OldServer
If you are using rewrite which Apache server is handling the re-writing and how 
is this implemented?

Anyone else?
Martin
This e-mail communication and any attachments may contain confidential and 
privileged information for the use of the 
designated recipients named above. If you are not the intended recipient, you 
are hereby notified that you have received
this communication in error and that any review, disclosure, dissemination, 
distribution or copying of it or its 
contents
- Original Message - 
From: <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" 
Sent: Friday, October 27, 2006 8:19 AM
Subject: URL-Rewriting suddenly doesn't work any more


> 
> Hello!
> 
> I've got a very strange problem: I have activated URL-rewriting in
> webapps/application/META-INF/context.xml with . 
> This
> has been working fine until today. Suddenly, the server doesn't rewrite the
> URL's no more - there is no jession-id sent with the URL.
> 
> Does anybody have a hint where to look at?
> 
> It's totaly mysterious, because if I put the complete tomcat-directory to
> another machine, and start this application there, all is working fine again.
> 
> 
> 
> Kind regards,
> Andreas Hartmann
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

URL-Rewriting suddenly doesn't work any more

[Andreas . Hartmann]

Hello!

I've got a very strange problem: I have activated URL-rewriting in
webapps/application/META-INF/context.xml with . This
has been working fine until today. Suddenly, the server doesn't rewrite the
URL's no more - there is no jession-id sent with the URL.

Does anybody have a hint where to look at?

It's totaly mysterious, because if I put the complete tomcat-directory to
another machine, and start this application there, all is working fine again.



Kind regards,
Andreas Hartmann


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Not getting URL rewriting with

[Mon Cab]

Thanks Richard

It works with action=userlogin_display.  


--- Richard Yee <[EMAIL PROTECTED]> wrote:

> According to the documentation if you use href, the value passed will
> be 
> unchanged. It looks like you should use action=userlogin_display
> and the property and name attributes to set the action parameter.
> 
> -Richard
> 
> Mon Cab wrote:
> > I have a jsp page called link test (included below), However, the
> url
> > for *Login Link* is not being rewritten to include the jsessionid. 
> > Cookies are disabled on my browser, and jsessionid is being
> generated
> > for form submissions, but not for links.
> >
> > Am I missing something here?  Pleae help. 
> >
> >
> >
> > <%@ page contentType="text/html;charset=UTF-8" %>
> > <%@ taglib uri="/tags/struts-bean" prefix="bean" %>
> > <%@ taglib uri="/tags/struts-html" prefix="html" %>
> > <%@ taglib uri="/tags/struts-logic" prefix="logic" %>
> > <%@ taglib uri="/WEB-INF/struts-tiles.tld" prefix="tiles" %>
> >
> >
> > 
> >
> > Title
> >
> > 
> >
> > 
> >   
> > 
> > 
> >   *Login Link*
> > 
> > 
> >
> > 
> >
> > 
> >
> > 
> >
> >
> >
> > This is rendering as: 
> >
> >
> > 
> >
> > Title
> >
> > > src='http://127.0.0.1:3005/js.cgi?caw&r=15006'>
> >
> > 
> >
> > 
> >
> > 
> >   
> > 
> >   *Login Link*
> >
> > 
> >
> > 
> >
> > 
> >
> > 
> >
> > __
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around 
> > http://mail.yahoo.com 
> >
> > __
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around 
> > http://mail.yahoo.com 
> >
> >
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >   
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Not getting URL rewriting with

[Richard Yee]

According to the documentation if you use href, the value passed will be 
unchanged. It looks like you should use action=userlogin_display

and the property and name attributes to set the action parameter.

-Richard

Mon Cab wrote:

I have a jsp page called link test (included below), However, the url
for *Login Link* is not being rewritten to include the jsessionid. 
Cookies are disabled on my browser, and jsessionid is being generated

for form submissions, but not for links.

Am I missing something here?  Pleae help. 




<%@ page contentType="text/html;charset=UTF-8" %>
<%@ taglib uri="/tags/struts-bean" prefix="bean" %>
<%@ taglib uri="/tags/struts-html" prefix="html" %>
<%@ taglib uri="/tags/struts-logic" prefix="logic" %>
<%@ taglib uri="/WEB-INF/struts-tiles.tld" prefix="tiles" %>




Title




  
  

  *Login Link*


   








This is rendering as: 





Title

   






  

  *Login Link*


   






__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Not getting URL rewriting with

[Mon Cab]

I have a jsp page called link test (included below), However, the url
for *Login Link* is not being rewritten to include the jsessionid. 
Cookies are disabled on my browser, and jsessionid is being generated
for form submissions, but not for links.

Am I missing something here?  Pleae help. 



<%@ page contentType="text/html;charset=UTF-8" %>
<%@ taglib uri="/tags/struts-bean" prefix="bean" %>
<%@ taglib uri="/tags/struts-html" prefix="html" %>
<%@ taglib uri="/tags/struts-logic" prefix="logic" %>
<%@ taglib uri="/WEB-INF/struts-tiles.tld" prefix="tiles" %>




Title




  


  *Login Link*


   








This is rendering as: 




Title

   






  

  *Login Link*


   






__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

problem on url rewriting and cookies , what is differences

[Legolas Woodland]

Hi
Thank you for reading my post
I have a problem with my hosted application , when i click on some of my
links in the web application
the server return an exception like :


java.lang.IllegalArgumentException: Path http://www.mysite.com/ does not
start with a "/" character

org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1062)

org.apache.struts.action.RequestProcessor.processForwardConfig(RequestProcessor.java:455)

org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:279)
   org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
   org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
   javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
   javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:118)

com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52)


For example that come from clicking a link that change the language.
also i used dynamic forward creation
in the web site that i build . the above exception come when i click on
one of my flags
which produce a url like :

http://www.mysite.com/ChangeLocale.do;jsessionid=2B7855F5F585B96C83B68FBC6B4E78D4?Lang=en

, but when the browser shows the exception if i click GO button of
browser again it will works fine.

I contact the host provider and ask them to give me some help (this
problem introduced after we
moved our web application to new host)
they said :

It looks like a bug in tomcat. Please force your application not to do
url rewriting and use cookies instead. This should solve your problem.

When i ask them about tomcat version they said :
its tomcat 5.5.15 , meanwhile my application works fine on tomcat 5.5.12
my questions are :
What that solution means ?
does tomcat 5.5.15 has that problem ?


Thanks



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

problem on url rewriting and cookies ,

[Legolas Woodland]

Hi
Thank you for reading my post
I have a problem with my hosted application , when i click on some of my 
links in the web application

the server return an exception like :


java.lang.IllegalArgumentException: Path http://www.mysite.com/ does not 
start with a "/" character
  
org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1062)
  
org.apache.struts.action.RequestProcessor.processForwardConfig(RequestProcessor.java:455)
  
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:279)

   org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
   org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
   javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
   javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
  
com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:118)
  
com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52)



For example that come from clicking a link that change the language. 
also i used dynamic forward creation
in the web site that i build . the above exception come when i click on 
one of my flags

which produce a url like :

http://www.mysite.com/ChangeLocale.do;jsessionid=2B7855F5F585B96C83B68FBC6B4E78D4?Lang=en

, but when the browser shows the exception if i click GO button of 
browser again it will works fine.


I contact the host provider and ask them to give me some help (this 
problem introduced after we

moved our web application to new host)
they said :

It looks like a bug in tomcat. Please force your application not to do 
url rewriting and use cookies instead. This should solve your problem.


When i ask them about tomcat version they said :
its tomcat 5.5.15 , meanwhile my application works fine on tomcat 5.5.12
my questions are :
What that solution means ?
does tomcat 5.5.15 has that problem ?


Thanks


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Forcing URL Rewriting over Cookies in an existing application.

[Laurie Harper]

Having the session ID in the URL is a concern if your site includes 
links to unknown third party sites (e.g. if you're displaying email with 
links in); you open yourself up to a 'referrer attack', where a 
malicious user can hijack your session by getting you to click a link to 
his site and examining his referrer logs. That's one reason cookies are 
the preferred mechanism.


L.

David G. Friedman wrote:

Bernhard,

Does it really matter?  In most Java application servers, don't they do both 
for the first request but after the second
request, where cookies are detected to be on, they stop using url rewriting.  
Or do those first two communications scare
you? ;)  Besides, a packet sniffer could see the cookie being transmitted every 
time anyway so does it really matter if
the cookie is in the browser URL line or being transmitted before the URL in 
the cookie header value for the HTTP
request call?

Regards,
David

-Original Message-
From: Bernhard Slominski [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 24, 2006 3:26 AM
To: 'Struts Users Mailing List'
Subject: AW: Forcing URL Rewriting over Cookies in an existing
application.



-Ursprüngliche Nachricht-
Von: David G. Friedman [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 23. Januar 2006 18:10

What do you mean by "do it the other way around" ?


Well I mean that you ONLY use cookies for the session management and not URL
Rewriting, you might want to do that for security reason, because when using
URL Rewriting the Session ID is in the address line and the cache, so a
pssoble security risk.

I think this should be contollable in a standard way and not
container-specific.

Bernhard


-Original Message-
From: Bernhard Slominski [mailto:[EMAIL PROTECTED]
Sent: Monday, January 23, 2006 11:34 AM
To: 'Struts Users Mailing List'
Subject: AW: Forcing URL Rewriting over Cookies in an existing
application.


Thank you!
But it's not possible to do it the other way round in Tomcat right ?
Also I think this should belong in the web.xml and shouldn't be
container-specific, what do you think?

Bernhard


-Ursprüngliche Nachricht-
Von: David G. Friedman [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 23. Januar 2006 17:28
An: Struts Users Mailing List
Betreff: RE: Forcing URL Rewriting over Cookies in an existing
application.


The same thing (disable cookies but enable url rewriting)
should work on Tomcat 4.X and 5.X.  See  the "cookies"
attribute in the below url(s):

http://tomcat.apache.org/tomcat-4.0-doc/config/context.html
http://tomcat.apache.org/tomcat-5.0-doc/config/context.html
http://tomcat.apache.org/tomcat-5.5-doc/config/context.html

Regards,
David

-Original Message-
From: Bernhard Slominski [mailto:[EMAIL PROTECTED]
Sent: Monday, January 23, 2006 11:20 AM
To: 'Struts Users Mailing List'
Subject: AW: Forcing URL Rewriting over Cookies in an existing
application.


OT, but I'm interested, is this available im Tomcat too?

Thanks

Bernhard


-Ursprüngliche Nachricht-
Von: David G. Friedman [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 23. Januar 2006 17:08
An: Struts Users Mailing List
Betreff: RE: Forcing URL Rewriting over Cookies in an existing
application.


http://access1.sun.com/techarticles/sessions.iws.html

Regards,
David

-Original Message-
From: Jay [mailto:[EMAIL PROTECTED]
Sent: Monday, January 23, 2006 10:53 AM
To: user@struts.apache.org
Subject: Forcing URL Rewriting over Cookies in an existing
application.


Hi all, I have an application (Sun ONE 6.1 sp2, Struts 1.02
(I guess)) that uses Cookies for session handling and has
been so for around 3/4 years. I have a requirement where I
want to force URL Rewriting even if the browser supports
cookies. Please help! Jay


Broadband interface (RIA) + mail box saftey =
http://Struts_User_List.roomity.com
*Your* clubs, no sign up to read, ad supported; try broadband
internet.




-

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Forcing URL Rewriting over Cookies in an existing application.

[David G. Friedman]

Bernhard,

Does it really matter?  In most Java application servers, don't they do both 
for the first request but after the second
request, where cookies are detected to be on, they stop using url rewriting.  
Or do those first two communications scare
you? ;)  Besides, a packet sniffer could see the cookie being transmitted every 
time anyway so does it really matter if
the cookie is in the browser URL line or being transmitted before the URL in 
the cookie header value for the HTTP
request call?

Regards,
David

-Original Message-
From: Bernhard Slominski [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 24, 2006 3:26 AM
To: 'Struts Users Mailing List'
Subject: AW: Forcing URL Rewriting over Cookies in an existing
application.


> -Ursprüngliche Nachricht-
> Von: David G. Friedman [mailto:[EMAIL PROTECTED]
> Gesendet: Montag, 23. Januar 2006 18:10
>
> What do you mean by "do it the other way around" ?
>
Well I mean that you ONLY use cookies for the session management and not URL
Rewriting, you might want to do that for security reason, because when using
URL Rewriting the Session ID is in the address line and the cache, so a
pssoble security risk.

I think this should be contollable in a standard way and not
container-specific.

Bernhard

>
> -Original Message-
> From: Bernhard Slominski [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 23, 2006 11:34 AM
> To: 'Struts Users Mailing List'
> Subject: AW: Forcing URL Rewriting over Cookies in an existing
> application.
>
>
> Thank you!
> But it's not possible to do it the other way round in Tomcat right ?
> Also I think this should belong in the web.xml and shouldn't be
> container-specific, what do you think?
>
> Bernhard
>
> > -Ursprüngliche Nachricht-
> > Von: David G. Friedman [mailto:[EMAIL PROTECTED]
> > Gesendet: Montag, 23. Januar 2006 17:28
> > An: Struts Users Mailing List
> > Betreff: RE: Forcing URL Rewriting over Cookies in an existing
> > application.
> >
> >
> > The same thing (disable cookies but enable url rewriting)
> > should work on Tomcat 4.X and 5.X.  See  the "cookies"
> > attribute in the below url(s):
> >
> > http://tomcat.apache.org/tomcat-4.0-doc/config/context.html
> > http://tomcat.apache.org/tomcat-5.0-doc/config/context.html
> > http://tomcat.apache.org/tomcat-5.5-doc/config/context.html
> >
> > Regards,
> > David
> >
> > -Original Message-
> > From: Bernhard Slominski [mailto:[EMAIL PROTECTED]
> > Sent: Monday, January 23, 2006 11:20 AM
> > To: 'Struts Users Mailing List'
> > Subject: AW: Forcing URL Rewriting over Cookies in an existing
> > application.
> >
> >
> > OT, but I'm interested, is this available im Tomcat too?
> >
> > Thanks
> >
> > Bernhard
> >
> > > -Ursprüngliche Nachricht-
> > > Von: David G. Friedman [mailto:[EMAIL PROTECTED]
> > > Gesendet: Montag, 23. Januar 2006 17:08
> > > An: Struts Users Mailing List
> > > Betreff: RE: Forcing URL Rewriting over Cookies in an existing
> > > application.
> > >
> > >
> > > http://access1.sun.com/techarticles/sessions.iws.html
> > >
> > > Regards,
> > > David
> > >
> > > -----Original Message-
> > > From: Jay [mailto:[EMAIL PROTECTED]
> > > Sent: Monday, January 23, 2006 10:53 AM
> > > To: user@struts.apache.org
> > > Subject: Forcing URL Rewriting over Cookies in an existing
> > > application.
> > >
> > >
> > > Hi all, I have an application (Sun ONE 6.1 sp2, Struts 1.02
> > > (I guess)) that uses Cookies for session handling and has
> > > been so for around 3/4 years. I have a requirement where I
> > > want to force URL Rewriting even if the browser supports
> > > cookies. Please help! Jay
> > >
> > >
> > > Broadband interface (RIA) + mail box saftey =
> > > http://Struts_User_List.roomity.com
> > > *Your* clubs, no sign up to read, ad supported; try broadband
> > > internet.
> > >
> > >
> > >
> >
> -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> >
> >
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> --

AW: Forcing URL Rewriting over Cookies in an existing application .

[Bernhard Slominski]

> -Ursprüngliche Nachricht-
> Von: David G. Friedman [mailto:[EMAIL PROTECTED]
> Gesendet: Montag, 23. Januar 2006 18:10
> 
> What do you mean by "do it the other way around" ?
> 
Well I mean that you ONLY use cookies for the session management and not URL
Rewriting, you might want to do that for security reason, because when using
URL Rewriting the Session ID is in the address line and the cache, so a
pssoble security risk.

I think this should be contollable in a standard way and not
container-specific.

Bernhard

> 
> -Original Message-
> From: Bernhard Slominski [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 23, 2006 11:34 AM
> To: 'Struts Users Mailing List'
> Subject: AW: Forcing URL Rewriting over Cookies in an existing
> application.
> 
> 
> Thank you!
> But it's not possible to do it the other way round in Tomcat right ?
> Also I think this should belong in the web.xml and shouldn't be
> container-specific, what do you think?
> 
> Bernhard
> 
> > -Ursprüngliche Nachricht-
> > Von: David G. Friedman [mailto:[EMAIL PROTECTED]
> > Gesendet: Montag, 23. Januar 2006 17:28
> > An: Struts Users Mailing List
> > Betreff: RE: Forcing URL Rewriting over Cookies in an existing
> > application.
> >
> >
> > The same thing (disable cookies but enable url rewriting)
> > should work on Tomcat 4.X and 5.X.  See  the "cookies"
> > attribute in the below url(s):
> >
> > http://tomcat.apache.org/tomcat-4.0-doc/config/context.html
> > http://tomcat.apache.org/tomcat-5.0-doc/config/context.html
> > http://tomcat.apache.org/tomcat-5.5-doc/config/context.html
> >
> > Regards,
> > David
> >
> > -Original Message-
> > From: Bernhard Slominski [mailto:[EMAIL PROTECTED]
> > Sent: Monday, January 23, 2006 11:20 AM
> > To: 'Struts Users Mailing List'
> > Subject: AW: Forcing URL Rewriting over Cookies in an existing
> > application.
> >
> >
> > OT, but I'm interested, is this available im Tomcat too?
> >
> > Thanks
> >
> > Bernhard
> >
> > > -Ursprüngliche Nachricht-
> > > Von: David G. Friedman [mailto:[EMAIL PROTECTED]
> > > Gesendet: Montag, 23. Januar 2006 17:08
> > > An: Struts Users Mailing List
> > > Betreff: RE: Forcing URL Rewriting over Cookies in an existing
> > > application.
> > >
> > >
> > > http://access1.sun.com/techarticles/sessions.iws.html
> > >
> > > Regards,
> > > David
> > >
> > > -Original Message-
> > > From: Jay [mailto:[EMAIL PROTECTED]
> > > Sent: Monday, January 23, 2006 10:53 AM
> > > To: user@struts.apache.org
> > > Subject: Forcing URL Rewriting over Cookies in an existing
> > > application.
> > >
> > >
> > > Hi all, I have an application (Sun ONE 6.1 sp2, Struts 1.02
> > > (I guess)) that uses Cookies for session handling and has
> > > been so for around 3/4 years. I have a requirement where I
> > > want to force URL Rewriting even if the browser supports
> > > cookies. Please help! Jay
> > >
> > >
> > > Broadband interface (RIA) + mail box saftey =
> > > http://Struts_User_List.roomity.com
> > > *Your* clubs, no sign up to read, ad supported; try broadband
> > > internet.
> > >
> > >
> > >
> > 
> -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> >
> > 
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> > 
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Forcing URL Rewriting over Cookies in an existing application.

[David G. Friedman]

What do you mean by "do it the other way around" ?

URL Rewriting is in the servlet spec 2.2 and beyond, hence the ability in Java 
to determine if the JSessionId was in a
Cookie, URL, or both, but I don't know if there is a standard web.xml syntax.  
I have read that context.xml files are
common on different java web servers so it might work out of the box, depending 
where (which directory) you put your
context.xml file.

Regards,
David

-Original Message-
From: Bernhard Slominski [mailto:[EMAIL PROTECTED]
Sent: Monday, January 23, 2006 11:34 AM
To: 'Struts Users Mailing List'
Subject: AW: Forcing URL Rewriting over Cookies in an existing
application.


Thank you!
But it's not possible to do it the other way round in Tomcat right ?
Also I think this should belong in the web.xml and shouldn't be
container-specific, what do you think?

Bernhard

> -Ursprüngliche Nachricht-
> Von: David G. Friedman [mailto:[EMAIL PROTECTED]
> Gesendet: Montag, 23. Januar 2006 17:28
> An: Struts Users Mailing List
> Betreff: RE: Forcing URL Rewriting over Cookies in an existing
> application.
>
>
> The same thing (disable cookies but enable url rewriting)
> should work on Tomcat 4.X and 5.X.  See  the "cookies"
> attribute in the below url(s):
>
> http://tomcat.apache.org/tomcat-4.0-doc/config/context.html
> http://tomcat.apache.org/tomcat-5.0-doc/config/context.html
> http://tomcat.apache.org/tomcat-5.5-doc/config/context.html
>
> Regards,
> David
>
> -Original Message-
> From: Bernhard Slominski [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 23, 2006 11:20 AM
> To: 'Struts Users Mailing List'
> Subject: AW: Forcing URL Rewriting over Cookies in an existing
> application.
>
>
> OT, but I'm interested, is this available im Tomcat too?
>
> Thanks
>
> Bernhard
>
> > -Ursprüngliche Nachricht-
> > Von: David G. Friedman [mailto:[EMAIL PROTECTED]
> > Gesendet: Montag, 23. Januar 2006 17:08
> > An: Struts Users Mailing List
> > Betreff: RE: Forcing URL Rewriting over Cookies in an existing
> > application.
> >
> >
> > http://access1.sun.com/techarticles/sessions.iws.html
> >
> > Regards,
> > David
> >
> > -Original Message-
> > From: Jay [mailto:[EMAIL PROTECTED]
> > Sent: Monday, January 23, 2006 10:53 AM
> > To: user@struts.apache.org
> > Subject: Forcing URL Rewriting over Cookies in an existing
> > application.
> >
> >
> > Hi all, I have an application (Sun ONE 6.1 sp2, Struts 1.02
> > (I guess)) that uses Cookies for session handling and has
> > been so for around 3/4 years. I have a requirement where I
> > want to force URL Rewriting even if the browser supports
> > cookies. Please help! Jay
> >
> >
> > Broadband interface (RIA) + mail box saftey =
> > http://Struts_User_List.roomity.com
> > *Your* clubs, no sign up to read, ad supported; try broadband
> > internet.
> >
> >
> >
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: Forcing URL Rewriting over Cookies in an existing application .

[Bernhard Slominski]

Thank you!
But it's not possible to do it the other way round in Tomcat right ?
Also I think this should belong in the web.xml and shouldn't be
container-specific, what do you think?

Bernhard

> -Ursprüngliche Nachricht-
> Von: David G. Friedman [mailto:[EMAIL PROTECTED]
> Gesendet: Montag, 23. Januar 2006 17:28
> An: Struts Users Mailing List
> Betreff: RE: Forcing URL Rewriting over Cookies in an existing
> application.
> 
> 
> The same thing (disable cookies but enable url rewriting) 
> should work on Tomcat 4.X and 5.X.  See  the "cookies"
> attribute in the below url(s):
> 
> http://tomcat.apache.org/tomcat-4.0-doc/config/context.html
> http://tomcat.apache.org/tomcat-5.0-doc/config/context.html
> http://tomcat.apache.org/tomcat-5.5-doc/config/context.html
> 
> Regards,
> David
> 
> -Original Message-
> From: Bernhard Slominski [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 23, 2006 11:20 AM
> To: 'Struts Users Mailing List'
> Subject: AW: Forcing URL Rewriting over Cookies in an existing
> application.
> 
> 
> OT, but I'm interested, is this available im Tomcat too?
> 
> Thanks
> 
> Bernhard
> 
> > -Ursprüngliche Nachricht-
> > Von: David G. Friedman [mailto:[EMAIL PROTECTED]
> > Gesendet: Montag, 23. Januar 2006 17:08
> > An: Struts Users Mailing List
> > Betreff: RE: Forcing URL Rewriting over Cookies in an existing
> > application.
> >
> >
> > http://access1.sun.com/techarticles/sessions.iws.html
> >
> > Regards,
> > David
> >
> > -Original Message-
> > From: Jay [mailto:[EMAIL PROTECTED]
> > Sent: Monday, January 23, 2006 10:53 AM
> > To: user@struts.apache.org
> > Subject: Forcing URL Rewriting over Cookies in an existing
> > application.
> >
> >
> > Hi all, I have an application (Sun ONE 6.1 sp2, Struts 1.02
> > (I guess)) that uses Cookies for session handling and has
> > been so for around 3/4 years. I have a requirement where I
> > want to force URL Rewriting even if the browser supports
> > cookies. Please help! Jay
> >
> >
> > Broadband interface (RIA) + mail box saftey =
> > http://Struts_User_List.roomity.com
> > *Your* clubs, no sign up to read, ad supported; try broadband
> > internet.
> >
> >
> > 
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Forcing URL Rewriting over Cookies in an existing application.

[David G. Friedman]

The same thing (disable cookies but enable url rewriting) should work on Tomcat 
4.X and 5.X.  See  the "cookies"
attribute in the below url(s):

http://tomcat.apache.org/tomcat-4.0-doc/config/context.html
http://tomcat.apache.org/tomcat-5.0-doc/config/context.html
http://tomcat.apache.org/tomcat-5.5-doc/config/context.html

Regards,
David

-Original Message-
From: Bernhard Slominski [mailto:[EMAIL PROTECTED]
Sent: Monday, January 23, 2006 11:20 AM
To: 'Struts Users Mailing List'
Subject: AW: Forcing URL Rewriting over Cookies in an existing
application.


OT, but I'm interested, is this available im Tomcat too?

Thanks

Bernhard

> -Ursprüngliche Nachricht-
> Von: David G. Friedman [mailto:[EMAIL PROTECTED]
> Gesendet: Montag, 23. Januar 2006 17:08
> An: Struts Users Mailing List
> Betreff: RE: Forcing URL Rewriting over Cookies in an existing
> application.
>
>
> http://access1.sun.com/techarticles/sessions.iws.html
>
> Regards,
> David
>
> -Original Message-
> From: Jay [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 23, 2006 10:53 AM
> To: user@struts.apache.org
> Subject: Forcing URL Rewriting over Cookies in an existing
> application.
>
>
> Hi all, I have an application (Sun ONE 6.1 sp2, Struts 1.02
> (I guess)) that uses Cookies for session handling and has
> been so for around 3/4 years. I have a requirement where I
> want to force URL Rewriting even if the browser supports
> cookies. Please help! Jay
>
>
> Broadband interface (RIA) + mail box saftey =
> http://Struts_User_List.roomity.com
> *Your* clubs, no sign up to read, ad supported; try broadband
> internet.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: Forcing URL Rewriting over Cookies in an existing application .

[Bernhard Slominski]

OT, but I'm interested, is this available im Tomcat too?

Thanks

Bernhard

> -Ursprüngliche Nachricht-
> Von: David G. Friedman [mailto:[EMAIL PROTECTED]
> Gesendet: Montag, 23. Januar 2006 17:08
> An: Struts Users Mailing List
> Betreff: RE: Forcing URL Rewriting over Cookies in an existing
> application.
> 
> 
> http://access1.sun.com/techarticles/sessions.iws.html
> 
> Regards,
> David
> 
> -Original Message-
> From: Jay [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 23, 2006 10:53 AM
> To: user@struts.apache.org
> Subject: Forcing URL Rewriting over Cookies in an existing 
> application.
> 
> 
> Hi all, I have an application (Sun ONE 6.1 sp2, Struts 1.02 
> (I guess)) that uses Cookies for session handling and has
> been so for around 3/4 years. I have a requirement where I 
> want to force URL Rewriting even if the browser supports
> cookies. Please help! Jay
> 
> 
> Broadband interface (RIA) + mail box saftey = 
> http://Struts_User_List.roomity.com
> *Your* clubs, no sign up to read, ad supported; try broadband 
> internet.
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Forcing URL Rewriting over Cookies in an existing application.

[David G. Friedman]

http://access1.sun.com/techarticles/sessions.iws.html

Regards,
David

-Original Message-
From: Jay [mailto:[EMAIL PROTECTED]
Sent: Monday, January 23, 2006 10:53 AM
To: user@struts.apache.org
Subject: Forcing URL Rewriting over Cookies in an existing application.


Hi all, I have an application (Sun ONE 6.1 sp2, Struts 1.02 (I guess)) that 
uses Cookies for session handling and has
been so for around 3/4 years. I have a requirement where I want to force URL 
Rewriting even if the browser supports
cookies. Please help! Jay


Broadband interface (RIA) + mail box saftey = 
http://Struts_User_List.roomity.com
*Your* clubs, no sign up to read, ad supported; try broadband internet.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Forcing URL Rewriting over Cookies in an existing application.

[Emmanouil Batsis]

Jay wrote:


Hi all, I have an application (Sun ONE 6.1 sp2, Struts 1.02 (I guess)) that 
uses Cookies for session handling and has been so for around 3/4 years. I have 
a requirement where I want to force URL Rewriting even if the browser supports 
cookies. Please help! Jay




This is a container (appserver) configuration issue right?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Forcing URL Rewriting over Cookies in an existing application.

[Jay]

Hi all, I have an application (Sun ONE 6.1 sp2, Struts 1.02 (I guess)) that 
uses Cookies for session handling and has been so for around 3/4 years. I have 
a requirement where I want to force URL Rewriting even if the browser supports 
cookies. Please help! Jay


Broadband interface (RIA) + mail box saftey = 
http://Struts_User_List.roomity.com
*Your* clubs, no sign up to read, ad supported; try broadband internet. 

Re: How to disable URL rewriting for session id?

[Julian Kerr]

David G. Friedman wrote:


I just skimmed through cvs and have this idea for you:

Edit a copy of the Html Taglib's helper class,
org.apache.struts.taglibs.TagUtils, so any methods
that would pull in the session variable to append to
the new URL don't do that.  When it's built, put
it under WEB-INF/classes/org/apache/struts/taglibs
so Struts calls YOUR class, not the original.
 



David,

Nice plan!

I basically did as you suggested, and automatic URL rewriting no longer 
takes place.


(Removed calls to HttpServletResponse.encodeURL within 
org.apache.struts.taglib.TagUtils and org.apache.struts.taglib.html.FormTag)


Thanks,
Julian

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: How to disable URL rewriting for session id?

[David G. Friedman]

Julian,

I just skimmed through cvs and have this idea for you:

Edit a copy of the Html Taglib's helper class,
org.apache.struts.taglibs.TagUtils, so any methods
that would pull in the session variable to append to
the new URL don't do that.  When it's built, put
it under WEB-INF/classes/org/apache/struts/taglibs
so Struts calls YOUR class, not the original.

I recommend reviewing the public Map computeParameters
method right after the comment:
// Add our transaction control token (if requested)

I'm sure older versions have some similar helper class
you can override with your own, for now.

FYI, to view this file on the web from the CVS/SVN repository, follow (this
will be wrapped, so you'll have to cut and paste it):
http://svn.apache.org/viewcvs.cgi/struts/taglib/trunk/src/java/org/apache/st
ruts/taglib/TagUtils.java?rev=202155&view=markup

Regards,
David

-Original Message-
From: Julian Kerr [mailto:[EMAIL PROTECTED]
Sent: Monday, July 04, 2005 1:25 AM
To: Struts Users Mailing List
Subject: Re: How to disable URL rewriting for session id?


Ahh, the problem spreadeth... also need to use plain old forms, which
means no struts help there either.

Guess this boils down to either finding a way to tell struts to stop
rewriting url's, or another moving to another context...

Julian


Wendy Smoak wrote:

>From: "Julian Kerr" <[EMAIL PROTECTED]>
>
>
>>A plain old html link would do the trick, but I'm keen to know if there
>>is a way to control the behaviour struts tags.
>>
>>
>>
>
>Just based on the docs, I'd say no... but I haven't looked any further than
>that.
>
>http://struts.apache.org/userGuide/struts-html.html#link
> says
>" URL rewriting will be applied automatically, to maintain session state in
>the absence of cookies. "
>
>Can you do URL-rewriting-in-reverse on the front end, and strip off the
>;jsessionid on the way in, before it causes a problem?
>
>Otherwise a plain old HTML link sounds like the way to go.
>
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to disable URL rewriting for session id?

[Julian Kerr]

Ahh, the problem spreadeth... also need to use plain old forms, which 
means no struts help there either.


Guess this boils down to either finding a way to tell struts to stop 
rewriting url's, or another moving to another context...


Julian


Wendy Smoak wrote:


From: "Julian Kerr" <[EMAIL PROTECTED]>
 


A plain old html link would do the trick, but I'm keen to know if there
is a way to control the behaviour struts tags.

   



Just based on the docs, I'd say no... but I haven't looked any further than
that.

http://struts.apache.org/userGuide/struts-html.html#link
says
" URL rewriting will be applied automatically, to maintain session state in
the absence of cookies. "

Can you do URL-rewriting-in-reverse on the front end, and strip off the
;jsessionid on the way in, before it causes a problem?

Otherwise a plain old HTML link sounds like the way to go.

 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to disable URL rewriting for session id?

[Wendy Smoak]

From: "Julian Kerr" <[EMAIL PROTECTED]>
>
> A plain old html link would do the trick, but I'm keen to know if there
> is a way to control the behaviour struts tags.
>

Just based on the docs, I'd say no... but I haven't looked any further than
that.

http://struts.apache.org/userGuide/struts-html.html#link
 says
" URL rewriting will be applied automatically, to maintain session state in
the absence of cookies. "

Can you do URL-rewriting-in-reverse on the front end, and strip off the
;jsessionid on the way in, before it causes a problem?

Otherwise a plain old HTML link sounds like the way to go.

-- 
Wendy Smoak


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to disable URL rewriting for session id?

[Julian Kerr]

Michael Jouravlev wrote:


On 6/30/05, Julian Kerr <[EMAIL PROTECTED]> wrote:
 


The html:link tag automatically applies URL rewriting to maintain
session state in the absence of cookies. Is it possible to disable this
feature?
   



Have you tried   <%@ page session="false" %>   ?

Michael.
 



I am using sessions, but track them with cookies.

I'd like to disable url rewriting because of the combination of:
1) empirical testing shows that url rewriting sometimes occurs even when 
cookies are enabled
2) my context doesn't deal with rewritten url's (as described in the 
initial post)


If I can turn url rewriting off, the application will work in the given 
context for people with cookies enabled.


A plain old html link would do the trick, but I'm keen to know if there 
is a way to control the behaviour struts tags.


-- Julian

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to disable URL rewriting for session id?

[Michael Jouravlev]

On 6/30/05, Julian Kerr <[EMAIL PROTECTED]> wrote:
> The html:link tag automatically applies URL rewriting to maintain
> session state in the absence of cookies. Is it possible to disable this
> feature?

Have you tried   <%@ page session="false" %>   ?

Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

How to disable URL rewriting for session id?

[Julian Kerr]

Dear All,

The html:link tag automatically applies URL rewriting to maintain 
session state in the absence of cookies. Is it possible to disable this 
feature?


[I'm using Resin in a shared environment. Resin considers the sessionid 
as part of the URL address, and hence I get 404 errors.]


Also, as an aside, even if cookies are accepted by the browser, I've 
noticed that sessionid still periodically appears in the URL. Is this to 
be expected??


Cheers.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Using Apache URL Rewriting with Struts?

[Robin Ericsson]

Jonathan Corbin wrote:
Is there a better way to accomplish this?  Or am I stuck with Struts hacks for 
the time being?
You could try rewriting the url in your appserver instead. Haven't got 
time to try it myself yet though :(.

http://tuckey.org/urlrewrite/
--
Robin Ericsson
http://robin.vill.ha.kuddkrig.nu/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Using Apache URL Rewriting with Struts?

[Jonathan Corbin]

I'm using RewriteRule directives in my Apache config to redirect certain URLs 
to struts webapps, running under tomcat.

RewriteRule ^/my/webapp/url/(.*) /my-webapp/$1?paramIWantToAdd=31337
[QSA,PT]

This works fine, until it hits Struts code.  Struts seems to be hard coded to 
write server relative URLs.  So links on a page produced by struts have the 
wrong URL.



I would rather struts produce the following:



so that the /my/webapp/url is preserved, and the user never sees /my-webapp.

Another related problem is with session cookies.  Struts writes session 
cookies at the app context (which I believe is what the servlet spec 
requires), so the JSESSIONID cookie is written for the /my-webapp context, 
and as a result, is not sent in on the HttpRequest when a user requests 
a /my/webapp/url page.

I've successfully gotten around both problems by hacking the struts code a 
little, and disabling session cookies (instead using session tracking through 
URL rewriting, putting jsessionid=blah on the end of every url).  I'd like to 
avoid using a modified version of struts, however, so I'm wondering if there 
is a better way to accomplish URL rewriting.

The real goal of all my modifications is to have each user of my application 
use a different url, so that I can easily control what version of my 
application they are using.

So user A goes to http://webserver/appForA
and user B goes to http://webserver/appForB
both get redirected to version 1 of my app at
http://webserver/appv1

Then, a few months down the road, I want to move user A to version 2, but keep 
user b at version 1.

So I change user A's redirect to point to http://webserver/appv2

Is there a better way to accomplish this?  Or am I stuck with Struts hacks for 
the time being?
-- 
Jonathan Corbin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

url rewriting fails with multipart/form-data

[delbd]

Hello,

Using struts and tomcat to handle a file upload form, i noticed the following 
problem. If the browsers doesn't accept cookies or tomcat does not yet use 
cookies with the involved session (ie we are at first page so tomcat is still 
probing the browser), tomcat is unable to read the jsessionid from the url of 
the multipart/form-data encoded POST. Method request.getUserPrincipal() 
returns null. This does not happens if cookies are used (browser accept 
cookies and tomcat has finished probing the browser) or if the form is a non 
multipart one.

Does anyone knows how to, either
- Have tomcat be able to extract jsessionid from url when it is a multipart 
POST
- Have tomcat use exclusively cookies (no url rewriting)

This is a big problem here as it prevent us to send emails with links to 
fileupload struts form where authentification is required.

Thanks for help if any

-- 
David Delbecq
Royal Meteorological Institute of Belgium 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

url rewriting problem

[Brian Moseley]

(i don't think this made it through the first time i sent 
it, so i'm trying again. apologies if you get this twice.)

i'm getting some weird problems with url rewriting in a
struts 1.2.4 webapp.
specifically, the urls generated by the form, link, and
rewrite tags have an extra "/" prepended to them.
struts is mapped like so in web.xml:
   
 action
 /console/*
   
here are examples of what's happening:
   source: 
   output: //chandler.css
   source: 
   output: 
   source: 
   output: 
i don't have any modules configured in struts-xml. here's
the mapping for the page that generates the above output:
 
   
 
and here's the mapping for the action pointed to by the form:
 
   
   
 
i've attached the full web.xml and struts-config.xml, in
case something non-obvious is throwing me off.
thanks!

http://java.sun.com/xml/ns/j2ee";
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
 xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd";
 version="2.4">
  Chandler Sharing Server
  
javax.servlet.jsp.jstl.fmt.localizationContext
MessageResources
  
  
webdavlog
org.apache.slide.webdav.filter.LogFilter

  logFormat
  %T, %t, %P, %m, %s "%l", %i, %p


  outputToConsole
  false


  outputToServletLog
  true

  
  
webdavlog
webdav
  
  
webdav
org.apache.slide.webdav.WebdavServlet

  domain
  /WEB-INF/Domain.xml


  namespace
  chandler


  scope
  


  depth-limit
  3


  default-mime-type
  application/octet-stream


  default-servlet
  false


  directory-browsing
  true


  directory-browsing-hide-acl
  true


  directory-browsing-hide-locks
  true


  optimizePropfindOutput
  true


  debug
  0


  extendedAllprop
  false


  lockdiscoveryIncludesPrincipalURL
  false


  updateLastModified
  true

1

  root
  root


  user
  user

  
  
action
org.apache.struts.action.ActionServlet

  config
  /WEB-INF/struts-config.xml


  convertNull
  true

1
  
  
webdav
/share/*
  
  
action
/console/*
  
  

  html
  /WEB-INF/tld/struts-html-el.tld


  logic
  /WEB-INF/tld/struts-logic-el.tld


  tiles
  /WEB-INF/tld/struts-tiles-el.tld


  c
  /WEB-INF/tld/c.tld


  fmt
  /WEB-INF/tld/fmt.tld


  fn
  /WEB-INF/tld/fn.tld

  
  
java.lang.Throwable
/error
  
  

  shared files
  /share/*
  COPY
  DELETE
  GET
  HEAD
  LOCK
  MKCOL
  MOVE
  OPTIONS
  POST
  PROPFIND
  PROPPATCH
  PUT
  UNLOCK
  VERSION-CONTROL
  REPORT
  CHECKIN
  CHECKOUT
  UNCHECKOUT
  MKWORKSPACE
  UPDATE
  LABEL
  MERGE
  BASELINE-CONTROL
  MKACTIVITY
  ACL
  SEARCH
  BIND
  UNBIND
  REBIND
  SUBSCRIBE
  UNSUBSCRIBE
  POLL
  NOTIFY


  root
  user

  
  

  admin console
  /console/*


  root
  user

  
  
BASIC
Chandler Server
  
  
root
  
  
user
  




http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd";>



  

  
  
  
  

  

  

  

  

  

  

  
  
  



  



  
  
  



  



  



  
  

  

  

  

  


  

  


  

  

  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: url rewriting

[Craig McClanahan]

On Tue, 20 Jul 2004 09:08:39 -0700, Jim Barrows <[EMAIL PROTECTED]> wrote:
> >
> > > I think you can use url rewriting, and that won't put the
> > jsessionid on it.
> >
> > It's sort of the other way around :-).  The "jsessionid" parameter is
> > the *result* of performing URL rewriting.  If your browser client is
> > using cookies, this will only show on the first request for a session
> > - the container has to send the session id both ways (cookie and
> > rewriting) the first time, because it doesn't know whether or not the
> > client has cookies enabled.  When the second request comes in with a
> > cookie, the container notices and stops bothering to rewrite.
> 
> Ah... okay... did I miss this in the documentation?  If so, where is it?  I'd like 
> it for a reference.

The servlet specification, section SRV.7.1 talks about what servlet
containers are required to support.  You can get a copy from
<http://jcp.org/en/jsr/detail?id=154>.  You won't see a detailed
specification of the "send it both ways the first time" (unless you
read the Tomcat code, that is :-), but it's pretty much a natural
consequence of how cookies work -- until a cookie is returned, the
server has no way to know whether or not they are enabled.

Details of how session management is configured for a particular
server is, of course, specific to each server.  For Tomcat 5, for
example, check <http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/context.html>
... in particular, the "cookies" attribute lets you turn off using
cookies for session management.

Craig

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: url rewriting

[Jim Barrows]

> -Original Message-
> From: Craig McClanahan [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 20, 2004 8:57 AM
> To: Struts Users Mailing List
> Subject: Re: url rewriting
> 
> 
> > I think you can use url rewriting, and that won't put the 
> jsessionid on it.
> 
> It's sort of the other way around :-).  The "jsessionid" parameter is
> the *result* of performing URL rewriting.  If your browser client is
> using cookies, this will only show on the first request for a session
> - the container has to send the session id both ways (cookie and
> rewriting) the first time, because it doesn't know whether or not the
> client has cookies enabled.  When the second request comes in with a
> cookie, the container notices and stops bothering to rewrite.

Ah... okay... did I miss this in the documentation?  If so, where is it?  I'd like it 
for a reference.

> 
> > Since the jsessionid is what is used for session tracking, 
> you want to look at
> > changing how session tracking is done.
> 
> The Struts tags always do the URL rewriting calls for you, so that
> sessions "just work."  If you never want to see the rewritten URLs,
> most containers have a way to configure disabling this feature -- but,
> if you do, sessions will only work for clients that have cookies
> turned on.
> 
> Craig
> 
> 
> 
> > 
> > 
> > 
> > 
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> >
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: url rewriting

[Craig McClanahan]

> I think you can use url rewriting, and that won't put the jsessionid on it.

It's sort of the other way around :-).  The "jsessionid" parameter is
the *result* of performing URL rewriting.  If your browser client is
using cookies, this will only show on the first request for a session
- the container has to send the session id both ways (cookie and
rewriting) the first time, because it doesn't know whether or not the
client has cookies enabled.  When the second request comes in with a
cookie, the container notices and stops bothering to rewrite.

> Since the jsessionid is what is used for session tracking, you want to look at
> changing how session tracking is done.

The Struts tags always do the URL rewriting calls for you, so that
sessions "just work."  If you never want to see the rewritten URLs,
most containers have a way to configure disabling this feature -- but,
if you do, sessions will only work for clients that have cookies
turned on.

Craig



> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: url rewriting

[Jim Barrows]

> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] Behalf Of j h
> Sent: Tuesday, July 20, 2004 7:41 AM
> To: [EMAIL PROTECTED]
> Subject: url rewriting
> 
> 
> Is there a way to disable the jsessionid from being appended 
> to the url when a 
> form is submitted?

I think you can use url rewriting, and that won't put the jsessionid on it.  Since the 
jsessionid is what is used for session tracking, you want to look at changing how 
session tracking is done.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

url rewriting

[j h]

Is there a way to disable the jsessionid from being appended to the url when a 
form is submitted?


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

url rewriting

[Lesaint Sébastien]

Hi,

I'm using the following code : 
logout

The html code I get is the following :
logout

When I read the explanation about how the  tag works, I
understood the content of href attribute should be something more like :
"http://www.myserver.com/lec/logoutAction.do";

I do have an  tag in the  tag of the HTML page.

Anybody can tell me if I misunderstood or forgot to set up something ?

thanks

-- 
Seb'

Re: URL Rewriting

[Michael McGrady]

Why don't you rewrite UrlRedirect to UrlForward?
At 10:34 PM 5/23/2004, Morten wrote:
Hi!
We are using Struts 1.1 and Tomcat 4.1.x at our company.
We are considering to separate our urls from our struts configuration.
Instead of /news.do?articleid=43 we would like the url to look like this:
/news/article/43. Furthermore the generated html should contain urls of the
form /news/article/43. This change should happen as transparently as
possible for our Action classes.
We have found the UrlRewriteFilter at tuckey.org. However it only solves
part of the problem. The incoming requests will be translated correctly.
However,
the anchors in the generated html remains unchanged.
A solution could be to write our own HttpConnector and then implement our
own HttpServetResponse.encodeURL, which in turn will translate the links.
Do anyone on this list have an (better) alternative to this problem?
Thanks in advance
Morten Knudsen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

URL Rewriting

[Morten]

Hi!

We are using Struts 1.1 and Tomcat 4.1.x at our company.
We are considering to separate our urls from our struts configuration.
Instead of /news.do?articleid=43 we would like the url to look like this:
/news/article/43. Furthermore the generated html should contain urls of the
form /news/article/43. This change should happen as transparently as
possible for our Action classes.

We have found the UrlRewriteFilter at tuckey.org. However it only solves
part of the problem. The incoming requests will be translated correctly.
However,
the anchors in the generated html remains unchanged.

A solution could be to write our own HttpConnector and then implement our
own HttpServetResponse.encodeURL, which in turn will translate the links.

Do anyone on this list have an (better) alternative to this problem?

Thanks in advance
Morten Knudsen




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]