Hi bro, what is your problem?
On 1/23/06, Lixin Chu <[EMAIL PROTECTED]> wrote:
>
> may you would like to take a look at these two:
> Yale's CAS : http://www.ja-sig.org/wiki/display/CAS/Home
> Acegi : http://acegisecurity.org/
>
>
> >
> >
> >
> >
> >
> >
>
>
--
===
If you're using a real CSS2 browser like Firefox, you can use CSS to enlarge
fonts for the
language you specify:
span[lang='he'] {
font-size: 120%;
}
or maybe something as simple as:
span.rtl {
font-size: 120%;
}
That means you should output ...
PS: Good idea with the tag library extension.
may you would like to take a look at these two:
Yale's CAS : http://www.ja-sig.org/wiki/display/CAS/Home
Acegi : http://acegisecurity.org/
>
>
>
>
>
>
> Ok, I use a resource file for all text and then put it in the
> html page using c:out, etc. But, what about Hebrew & Arabic?
> They need to be marked with dir="RTL". I can make the message
> hi there but then I can't escape any
> text and have to make sure I have escaped things in my messages
Rick Reumann wrote:
The approach isn't invalid as far as basic validation, but for security
I'd say it was not the best way to handle it. Let me ask you and Paul
this... how many times do you see Struts application's built where if
you are "Role A" you see X Y Z links but if you are "Role B" yo
David, I am not sure what the problem is. How is this any different than LTR
text? You could use
so you don't have to escape anything.
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
Sending again (it's a work day now in the Middle East).
Thanks - dave
-Original Message-
Hi;
Ok, I use a resource file for all text and then put it in the html page
using c:out, etc. But, what about Hebrew & Arabic? They need to be marked
with dir="RTL". I can make the message hi there b
Rick,
It's a security risk because you're allowing in non-validated data. You could
pass in good data,
bad data, malicious data, etc. You could pass in a string that's a million
characters to your
database, perhaps characters that will appear in SQL, wrong ranges of numbers,
constantly causing
Paul Benedict wrote:
I don't do any business validation with the Validator; I just make sure I get
proper data formats
so that everything is in proper format when going into the service layers. I
want XYZ to be
integers and ABC to be strings.
Then where is the big 'security' risk? Worst case
Thanks Paul.
Aladin
Paul Benedict wrote:
Aladin,
You cannot nest JSP tags inside JSP tag attributes. Split them up:
JSP 1.2:
JSP 2.0:
Paul
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://m
Rick,
I don't do any business validation with the Validator; I just make sure I get
proper data formats
so that everything is in proper format when going into the service layers. I
want XYZ to be
integers and ABC to be strings.
Paul
__
Do You Yah
Frank W. Zammetti wrote:
You may be 100% right, but it's not especially relevant to this... I'm
sure you wouldn't say the solution is for everyone who is using
automatic validation now to rewrite their apps, are you? :)
No you are right there. I know people like the automatic validation
stu
Aladin,
You cannot nest JSP tags inside JSP tag attributes. Split them up:
JSP 1.2:
JSP 2.0:
Paul
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
Hello All,
I am trying to pass a string (defined in tiles-defs.xml) to my main
layout, to be used as a key in a tag.
My Setup:
In main-layout.jsp
===
...
"
link="<%=(String)request.getAttribute("page") %>"/>
...
In tiles-defs.xml
==
... page 1 ...
...
Laurie, one thing to correct:
Issue: addition of a 'org.apache.struts.action.CANCEL' parameter to any request
will cause
validation to be skipped, but the rest of the request processing / action
invocation cycle to
proceed normally
Should read:
Issue: addition of a 'org.apache.struts.taglib.ht
>>(Some of?) the DispactAction variants dispatch to a special method and aren't
>> subject to the
consequences listed above, but most action implementations don't.
Rick, let me correct something here:
The DispatchAction variants are also subject to the problem with
validate="true" WHEN there is
Rick Reumann wrote:
2) Use a DispatchAction. I really don't get why some of you are against
them:) Do you make separate "DaoForCreate" and "DaoForUpdate" objects?
My guess is you have one Dao that handles CRUD for a particular type of
concern. To me it's just annoying having separate actions f
OK, transplanted to dev then :)
Frank W. Zammetti wrote:
Excellent summary Laurie, thanks! I think you captured all the
pertinent information clearly and concisely. I just suggested to Paul
to open a ticket for this as well, that should probably be mentioned
(with a ticket # if available whe
Not going to rehash the issues including the issues in the new thread
started by Michael and the summary brought up by Laurie in that thread
(and yes Franks this thread is nested, somehow michael's message started
with a new messageId which breaks into a new top level thread for those
clients t
...you start a [FRIDAY] thread on comp.jakarta.struts.user.
G.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Excellent summary Laurie, thanks! I think you captured all the
pertinent information clearly and concisely. I just suggested to Paul
to open a ticket for this as well, that should probably be mentioned
(with a ticket # if available when you post). Two minor comments below...
Frank
Laurie H
[Moved to a top-level thread, as this doesn't have anything to do with
(either of) the thread(s) it was nested in! :-)]
I think this thread deserves discussion on the dev list, but before I
move it over I thought I'd post a summary to make sure I've captured all
the arguments. I've also added
P.S., Paul, I'd suggest going ahead and opening a ticket for this and
reference this thread... say that a couple of different solutions were
suggested and patches can be easily created once a consensus on the
right answer is reached (I know you said you'd create a patch, and I
would too if nece
Paul Benedict wrote:
Cancelable Actions (independently on the Action type: normal Actions,
DispatchActions) could
even implement a Cancelable interface with a cancel method.
Tamas, good one. I thought of this too but never mentioned it because
implementing interfaces
doesn't seem too cool/acc
Thanks Craig, that was exactly the right solution. I'm using Tomcat
5.5.12 and adding the dispather elements to the shale filter-mapping did
the trick perfectly.
Thanks again,
Rich
Craig McClanahan wrote:
On 1/21/06, Richard Wallace <[EMAIL PROTECTED]> wrote:
Hello again,
I'm running in
On 1/21/06, Paul Benedict <[EMAIL PROTECTED]> wrote:
> Try it yourself!! Just add "?org.apache.struts.taglib.html.CANCEL=true" to
> any GET URL and your
> execute() method will magically be called as if you didn't have any
> validation added to your code.
Calling ActionForm.validate() explicitly
>> Cancelable Actions (independently on the Action type: normal Actions,
>> DispatchActions) could
even implement a Cancelable interface with a cancel method.
Tamas, good one. I thought of this too but never mentioned it because
implementing interfaces
doesn't seem too cool/accepted in the Strut
>> If everyone used dispatch-type Actions, I would disagree because then it
>> would just be a matter
of providing a cancel() method and making sure that got called.
There's actually a funny bug here. cancel() method ALWAYS gets called in a
dispatch action BUT
it's default behavior is to retur
>
> Interestingly, the doc for the cancel tag *does* say that validate()
> won't be called and that the Action will be called normally. I never
> noticed this before. So, at least no one can claim this behavior isn't
> documented :)
Yes, but if you don't want to use the cancel tag you probably
If everyone used dispatch-type Actions, I would disagree because then it
would just be a matter of providing a cancel() method and making sure
that got called. But, since not everyone does (including me whenever I
can avoid it), that's not the end of the story.
Interestingly, the doc for the
I'm not sure this solves the problem Rick... partially it does...
As Paul pointed out, the cancel function itself is a legitimate case.
In that situation, you wouldn't want the form to be populated (you
wouldn't care if it was or wasn't I suppose, but ideally why bother
doing the extra work?)
All of this just adds *ONE MORE REASON* to my list of *NEVER EVER* use
validate="true". I always call validation manually from my Action class
and the sooner people get into a habit of this the way better off they
will be. If you validate or call the form's validate method manually
from your Ac
Tamas Szabo on 22/01/06 07:30, wrote:
There is a legitimate case: when an form can be cancelled, you do
want to skip client-side and server-side validation. That's just
fine because in these case you do want to call the cancelled()
method from DispatchAction, dump out any state you collected, an
33 matches
Mail list logo
