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 t
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
@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 wan
...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 mo
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
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.
> > 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
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,
> >> > 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 h
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 - th
> > 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 co
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
> >> 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 a
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
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 n
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 framew
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
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.
> Ho
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
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
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
>
> 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
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 t
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 link
"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
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
>
>
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
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
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 ac
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
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.
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 a
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 (
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 defau
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
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 b
> -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
> 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 conta
> -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 ca
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/a
41 matches
Mail list logo