Re: Validation Security Hole?
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, and go to the appropriate forward. In my oppinion it isn't ahndled correctly and I don't think that it should be solved by configuration script. If the user presses Cancel then the processing should go on another path. It doesn't make sense to populate and to validate if cancel was pressed. I agree. I _do_ use the cancel button on many forms and this is what I implement - if Struts did it itself, it would save me time and effort. Plus it would be safer on other actions where I don't use the cancel button. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validation Security Hole?
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 Action class all these problems go away including the problem
we get posted here on the list at least a couple times a week concerning
list items going out of scope when validation fails. Validating manually
also solves the problem Paul addresses as form validation ALWAYS takes
place.
I think the bug is sort of in validate='true' :) I think that should
just be dropped and when people need to validate they just call it from
their Action class.
http://www.learntechnology.net/validate-manually.do
The code is this simple to add:
ActionErrors errors = form.validate( mapping, request );
if ( errors != null !errors.isEmpty ) {
saveErrors(request, errors);
setUp(request); //preps request for lists and stuff
return (mapping.findForward(UIconstants.VALIDATION_FAILURE));
}
You could even add that to a utility method so it's just one line of code.
Now you have either one line of code in your Action or one line of code
in your ActionMapping, yet the first scenario solves all these problems.
(side note, I don't even really like using the validator so I don't even
call form.validate() but call a validation method in my action class
that does my validation, but I know most like to use the validator so
I'm showing how easy it is to call manually).
Frank W. Zammetti wrote:
Rick Reumann wrote:
Maybe I'm missing how the above would happen. How would passing in the
canceled parameter end up getting them access to a table? Oh wait,
maybe this is with regular Actions with just an execute? It's been so
long since I used a non Dispatch Action I'm not aware of the behavior.
So I have an Action called GetMeATable with an execute method that
returns a table from the db, if I pass in through a get parameter the
canceled param it will still execute that action?
Right, ordinary Action we're talking about. All Struts does is put a
request attribute in place to indicate the Action is being canceled. It
then goes on to populate the form, but *NOT* call validate() on it. So,
the problem arises if your Action doesn't check for the canceled
attribute and validate() is meant to stop a given request (as in my
scenario where it was checking for one of the allowed table names).
As I Wrote this, I see that Paul responded and said it's a problem with
DispatchActions too, and I think he's right. In fact, his response sums
up my own pretty well :)
Even if the above is true, I'm not so sure that's a big deal as far as
Struts goes in regard to it being a 'security problem with Struts'.
You can always find a ton of security loop holes if you don't truly
check that the logged in user has access to some backend procedure.
For example if you have an update dispatch method or an UpdateAction
you could easily type in the url
someUrl?dispath=updateid=42whatever=something etc and have it go
through and be processed.
Well, let me put it this way... if I worked for Microsoft, to me at
least, this would be a non-critical bug. Patch it on the regular second
Tuesday of the month cycle :) But I *do* think it is a bug (a logic bug
in this case) and *is* a security hole, even if arguably a small one.
Your absolutely right though, there are far more severe security holes
that a developer can open up without help from Struts :) I don't think
that should make anyone less interested in plugging this one though.
Bottom line is if security is an issue, no one should ever rely on the
validate method. That's just silly. I'm sure the docs even state that
the purpose of the validate method is to just validate data entry
(required fields, no Strings in number fields, etc.).
But, how someone defines data entry can come into play... for
instance, in the scenario I described, selecting a table, from a select
say, would count as data entry, wouldn't it? Try this... let's say
we're talking about a *REALLY* bad developer and for some reason he has
a *TEXT* field for entering the table name, and then goes on to check if
it is an allowed value in validate(). Stupid design, in the extreme!
But an improper use of validate()? Probably not (debatable at least).
Let me try and come up with a better example...
Let's say my bank's web site allows me to have a primary user account,
and I can link to this account all my checking accounts and savings
account to see them all in one dashboard display. I have to fill out
a form to have an account added. The form has account number on it.
Let's say one of the validations is to be sure the checksum of the
entered account number matches one that would only be valid for me. It's
a relatively simple math check, so it's
Re: Validation Security Hole?
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?) and you wouldn't want validate() to be called
because it might reject the request when it shouldn't...
For example... say I have a 3-page wizard flow. After each page I stick
the entered values in session. On the third page I have the capability
of clicking cancel. When this occurs, I'm going to want to clear out
the stored values from session. Imagine that the last page *also* has
some entry fields that are usually validated, and let's say one of them
is required. If the user clicks cancel, whether you call validate from
the Action or not, the user is forced to enter a value just to get past
validation, even if they click cancel! The UI would appear broken to
the user, and rightly so.
Now, you may say that yeah, but I would call isCancelled() before I do
the validation, and indeed, that would make the UI work as it should.
The problem though is that you will have to remember to do that check IN
EVERY ACTION, or risk having a similar UI issue elsewhere. It's just
extra code you have to copy-and-paste, or have your own base Action
class to extend from.
I agree, if everyone did as you suggest this issue wouldn't be as
severe. In fact, you would take care of the security issue (assuming
*every* Action called validate()), but you would trade it in for a
broken UI mechanism anytime the cancel button was involved. Not as big
a deal, but still not the best answer :)
Frank
Rick Reumann wrote:
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 Action class all these problems go away including the problem
we get posted here on the list at least a couple times a week concerning
list items going out of scope when validation fails. Validating manually
also solves the problem Paul addresses as form validation ALWAYS takes
place.
I think the bug is sort of in validate='true' :) I think that should
just be dropped and when people need to validate they just call it from
their Action class.
http://www.learntechnology.net/validate-manually.do
The code is this simple to add:
ActionErrors errors = form.validate( mapping, request );
if ( errors != null !errors.isEmpty ) {
saveErrors(request, errors);
setUp(request); //preps request for lists and stuff
return (mapping.findForward(UIconstants.VALIDATION_FAILURE));
}
You could even add that to a utility method so it's just one line of code.
Now you have either one line of code in your Action or one line of code
in your ActionMapping, yet the first scenario solves all these problems.
(side note, I don't even really like using the validator so I don't even
call form.validate() but call a validation method in my action class
that does my validation, but I know most like to use the validator so
I'm showing how easy it is to call manually).
Frank W. Zammetti wrote:
Rick Reumann wrote:
Maybe I'm missing how the above would happen. How would passing in
the canceled parameter end up getting them access to a table? Oh
wait, maybe this is with regular Actions with just an execute? It's
been so long since I used a non Dispatch Action I'm not aware of the
behavior. So I have an Action called GetMeATable with an execute
method that returns a table from the db, if I pass in through a get
parameter the canceled param it will still execute that action?
Right, ordinary Action we're talking about. All Struts does is put a
request attribute in place to indicate the Action is being canceled.
It then goes on to populate the form, but *NOT* call validate() on
it. So, the problem arises if your Action doesn't check for the
canceled attribute and validate() is meant to stop a given request (as
in my scenario where it was checking for one of the allowed table names).
As I Wrote this, I see that Paul responded and said it's a problem
with DispatchActions too, and I think he's right. In fact, his
response sums up my own pretty well :)
Even if the above is true, I'm not so sure that's a big deal as far
as Struts goes in regard to it being a 'security problem with
Struts'. You can always find a ton of security loop holes if you
don't truly check that the logged in user has access to some backend
procedure. For example if you have an update dispatch method or an
UpdateAction you could easily type in the url
someUrl?dispath=updateid=42whatever=something etc and have it go
through and be processed.
Well, let me put it this way... if I
Re: Validation Security Hole?
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 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 :) There's really two problems here... one revolves around how this feature maybe should have been designed in the first place. Tamas may be right in that regard. The second problem though is you have apps built with it the way it is now, for better or worse, and breaking those to close this hole isn't really the best idea. With that in mind, I'm thinking something along the lines of Paul's original suggestion may in fact be the best... add a cancelable attribute to the action element in config. Default to true. When set to false and the Action is called, that's the hacker case we want to avoid... maybe throw an IllegalStateException? Maybe look for an illegalCancel forward? Not sure what's best, but the point is to avoid calling execute() in that case. This would maintain the existing behavior by default too. No, actually, better yet, as Paul suggested, add cancelable to the processor element as well. I think you really need it to be on both processor and action though... set it to false on the processor to globally close the security hole, then set it to true on the action's where it applies. Frank Adam Hardy wrote: 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, and go to the appropriate forward. In my oppinion it isn't ahndled correctly and I don't think that it should be solved by configuration script. If the user presses Cancel then the processing should go on another path. It doesn't make sense to populate and to validate if cancel was pressed. I agree. I _do_ use the cancel button on many forms and this is what I implement - if Struts did it itself, it would save me time and effort. Plus it would be safer on other actions where I don't use the cancel button. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validation Security Hole?
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 don't read its doc. And if you don't use it you wont put the if (isCancelled(request) ) check in your execute. And this is exactly the case when you could get in trouble ... There's really two problems here... one revolves around how this feature maybe should have been designed in the first place. Tamas may be right in that regard. The second problem though is you have apps built with it the way it is now, for better or worse, and breaking those to close this hole isn't really the best idea. Yes, it's very easy to criticize something after it was implemented. But I admit a solution that isn't backward compatible isn't viable. With that in mind, I'm thinking something along the lines of Paul's original suggestion may in fact be the best... add a cancelable attribute to the action element in config. Default to true. When set to false and the Action is called, that's the hacker case we want to avoid... maybe throw an IllegalStateException? Maybe look for an illegalCancel forward? Not sure what's best, but the point is to avoid calling execute() in that case. This would maintain the existing behavior by default too. No, actually, better yet, as Paul suggested, add cancelable to the processor element as well. I think you really need it to be on both processor and action though... set it to false on the processor to globally close the security hole, then set it to true on the action's where it applies. Well this seems to be backward compatible. But you will still have to add tha cancelable= true for all the mappings that can be cancelled in your existing applications. Frank Tamas
Re: Validation Security Hole?
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 return null; and if null is returned then it considers it non-implemented and goes to the intended method. That's actually a bug too because NULL is a legitmate return value from a struts action. If you handled the request directly, say by writing directly to the servlet OutputStream or HttpServletResponse.sendRedirect(), you're supposed to retun null. That's what the docs say =o) But in this case NULL means not implemented. Anyway, it must be the weekend because no one from the Struts team have chimed in -- but they deserve days off too. :) maybe ;) I'd like to actually have a solution to submit; I am going to implement my suggestion privately in my applications but I would like an official one get into Struts too. Paul __ 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: Validation Security Hole?
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 Struts framework yet. (But that will change in 1.3.) If I add a Cancelable interface to my actions, then that could indicate to the framework that these actions deserve to be canceled; otherwise ignore the request parameter. Rick, your suggestion is good too. Did you know Tapestry works the same way? You're in charge of calling the validator and determining what it should do. In your case you would always want the form populated so you could determine if to validate or not. Frank, I agree: I don't think it makes sense populating the form if validate=true and the cancel token is in the parameter. Besides, the extra benefit here is that if you're in a form wizard and you have 2 out of 3 pages validated, if they cancel on the 3rd page, you at least have 2 pages of data that you know is good; re-populating the form without validation then looses this confidence. Paul __ 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: Validation Security Hole?
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 from an action saves a lot of trouble, and for me it is just simpler. On 1/21/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: Now, imagine a hacker wants to get to a completely different table in the database (I suppose reading from a selected table would be a better example, but I digress). To do so, they can pass in the canceled parameter and whatever table name they want, assuming they can mangle the URL properly and establish a session first. Since Struts will populate the form and fire the Action *without* calling validate() in this case, the hacker has the in they want. I say it again, do not rely on automatic validation ;-) On 1/22/06, Rick Reumann [EMAIL PROTECTED] wrote: 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. +1. Also, I would prefer populate() to be explicitly called from action as well. I want framework to provide services for me and to do heavy lifting, but I want to control the steering wheel and pedals. Automatic behavior on request/response is a flaw, not a benefit. I can write 3-5 lines of code to perform (or not) appropriate framework function. I hate when stuff is done for me. A framework should encapsulate chunks of job, but it must be me to decide whether to perform these jobs or not. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Shale-Clay and jsp:forward
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 into a problem getting my /index.jsp to forward to a Clay HTML page. The index.jsp page just contains the following: jsp:forward page=default.html/ When I try to hit it with the URL http://localhost:8080/shale-clay-example/ I get a 404 saying that default.jsp cannot be found. If I goto http://localhost:8080/shale-clay-example/default.html it works just fine. Can I not forward to the default page like this? I also tried setting default.html as the welcome-file in the web.xml, but that didn't work (I didn't really expect it to). Any idea what the problem is? What container are you running on? In particular, is it based on Servlet 2.3 or 2.4? The reason this is important is that a RequestDispatcher.forward() (which is what a jsp:forward does under the covers) does *not* necessarily go through the entire lifecycle that an HTTP request to the forwarded-to URL would go to. In the particular case here, it's important that a request for a Clay-served view has to go through the Shale filter to do the approprate processing. This is impossible in a Servlet 2.3 environment, because filters are defined to *only* be applied on the original request, not on forwards. In a Servlet 2.4 environment (such as Tomcat 5.x), this remains the default ... but you can ask for filters to be applied by modifying your filter mapping declaration: filter-mapping filter-nameshale/filter-name url-pattern/*/url-pattern dispatcherREQUEST/dispatcher dispatcherFORWARD/dispatcher /filter-mapping This changes the default behavior (which only applies filters to requests) to apply the Shale filter to both requests and forwards. This *should* address the use case you are describing. Thanks, Rich Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validation Security Hole?
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/accepted in the Struts framework yet. (But that will change in 1.3.) If I add a Cancelable interface to my actions, then that could indicate to the framework that these actions deserve to be canceled; otherwise ignore the request parameter. I didn't think it was a good idea at first, but now I don't think it's a bad one. The first question is whether backwards-compatibility *should* be maintained... my usual stance is yes, it should be, and that was driving my suggestions before. Thinking about it more though, that's like Microsoft saying yes, we know this WMF flaw is a security issue, so we're going to provide a mechanism to patch the hole, but it's going to be optional on the part of developers... by default, the hole will continue to exist so that backwards-compatibility is maintained. We'd all yell they are crazy if they said that! No, in this case I think it makes sense to break compatibility. The question then becomes what is the least onerous way to do it so that someone upgrading an existing app has as little to do as possible while still being architecturally sound. Well, the config parameters would probably be the easiest way, but the interface seems more elegant architecturally. If I was maintaining an app and I wanted to close this security hole with the least amount of effort though, I would contend Paul's approach is probably better... If we assume the new cancelable attribute on the controller defaults to false, then I really just need to go through and add cancelable=true to any mappings that correspond to legitimately cancelable Actions, which chances are isn't many. Contrast this to having to go through and implement an interface and rebuild the app. Not a huge difference perhaps, but enough (and don't forget that some shops have rather onerous requirements before you could deploy the new build). The interface isn't a bad suggestion though, after thinking about it a bit. Either way :) Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validation Security Hole?
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 necessary once we can all come together to decide which way to go). This will put it more officially in front of the committers for their consideration, since ultimately they are going to have to decide if they agree this is an issue or not, and then agree with how to resolve it. The first step in all that is generally a ticket being opened. This is your baby, so go for it! :) Frank Paul Benedict wrote: 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 return null; and if null is returned then it considers it non-implemented and goes to the intended method. That's actually a bug too because NULL is a legitmate return value from a struts action. If you handled the request directly, say by writing directly to the servlet OutputStream or HttpServletResponse.sendRedirect(), you're supposed to retun null. That's what the docs say =o) But in this case NULL means not implemented. Anyway, it must be the weekend because no one from the Struts team have chimed in -- but they deserve days off too. :) maybe ;) I'd like to actually have a solution to submit; I am going to implement my suggestion privately in my applications but I would like an official one get into Struts too. Paul __ 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] . -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validation Security Hole?
[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 preliminary thoughts in how to resolve the issue at the end of this post, though that discussion definitely ought to proceed on the dev list I guess. I'll re-post this message to the dev list later today if I haven't missed anything important below: * 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 * Consequence: any action which proceeds assuming that validation has completed successfully and which doesn't explicitly check isCanceled() is proceeding on a broken assumption * Questions: - why doesn't Struts call validate() on a cancelled request? If a request is canceled it usually means validations don't apply since the implication is that any user input will be thrown away. Users shouldn't be required to supply valid inputs for actions they are canceling. - why does Struts still call Action.execute() for a canceled request? Since you may still want to act on a canceled request (e.g. to clean up resources stored in the session). (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. - why does Struts still populate the action form on a cancelled request? If inputs are going to be thrown away anyway, why process them by populating the action form? [Commentary: I believe this behaviour makes sense since it preserves a standard way to access the request data, should you want to, regardless of whether the action was canceled. You could argue that either way...] Here's my first thoughts on possible approaches to addressing the problem, to kick off further discussion on the dev list: - SAF1.2 and before: ? document, don't fix? add config req'm'ts on action mapping? Refer to discussion on user list for various options. - SAF1.3+: make cancel processing a command which you have to include in your request processing chain, and perhaps disclude it by default? [I'm not familiar enough with how you deploy chains on a per-action basis to know if this is the right way to do it...] - WW2/SAF2: implement cancel processing as an interceptor and either disclude it from default stack or require an action to implement an interface declaring that cancel processing should happen? L. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validation Security Hole?
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 Harper wrote: [Moved to a top-level thread, as this doesn't have anything to do with (either of) the thread(s) it was nested in! :-)] Was it nested? I didn't even notice :) 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 preliminary thoughts in how to resolve the issue at the end of this post, though that discussion definitely ought to proceed on the dev list I guess. I'll re-post this message to the dev list later today if I haven't missed anything important below: * 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 * Consequence: any action which proceeds assuming that validation has completed successfully and which doesn't explicitly check isCanceled() is proceeding on a broken assumption * Questions: - why doesn't Struts call validate() on a cancelled request? If a request is canceled it usually means validations don't apply since the implication is that any user input will be thrown away. Users shouldn't be required to supply valid inputs for actions they are canceling. - why does Struts still call Action.execute() for a canceled request? Since you may still want to act on a canceled request (e.g. to clean up resources stored in the session). (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. - why does Struts still populate the action form on a cancelled request? If inputs are going to be thrown away anyway, why process them by populating the action form? [Commentary: I believe this behaviour makes sense since it preserves a standard way to access the request data, should you want to, regardless of whether the action was canceled. You could argue that either way...] I tend to agree with your commentary, even though I find it hard to envision a situation where you'd want to get at the parameters. Certainly better to be able to though. Here's my first thoughts on possible approaches to addressing the problem, to kick off further discussion on the dev list: - SAF1.2 and before: ? document, don't fix? add config req'm'ts on action mapping? Refer to discussion on user list for various options. - SAF1.3+: make cancel processing a command which you have to include in your request processing chain, and perhaps disclude it by default? [I'm not familiar enough with how you deploy chains on a per-action basis to know if this is the right way to do it...] I think this would be affected by what is done with 1.2... if it is modified to by default not allow Actions to be cancelable for instance, I would think it would be better to replicate that change into 1.3, which would likely entail changing the default chain. Open for discussion obviously :) - WW2/SAF2: implement cancel processing as an interceptor and either disclude it from default stack or require an action to implement an interface declaring that cancel processing should happen? L. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [FRIDAY] You might be a Wally if ...
...you start a [FRIDAY] thread on comp.jakarta.struts.user. G. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validation Security Hole?
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 that base a thread on messageID - which they should:) Lastly, I never run into these problems because 1) I never liked the cancel button and its behavior. It's 'too behind the scenes' for me in the whole setting of an isCanceled param and all that jazz. To me it always made since to handle cancel with a true submit of the form and set the dispatch param to cancel or if using a Michael/McGrady/or Mapipng type of dispatch some other key. Then you simply handle it like any other Action. It's clean and easy to understand and you never have to worry about these under-the-cover things. 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 for related events, and it makes it more difficult when you want to do things related to these events. To each his/her own I guess:) 3) Call the validation framework manually. I can give several reasons why this is a good idea and saves the developer a lot of headaches, but I've been over it before (happy to readdress if someone wants me to:). It's not much more code to write and actually simplifies things (very easy to see what's going on by simply looking at your Action class). Anyway, that's my advice for anyone having trouble with Cancel issues. I do now see though the issue that Paul brings up and that Frank clarified and Laurie clarified further in the summary, although I still don't see it as high security risk since I would never rely on the validate method to handle something that could be that much of a risk. A bit more on that below in reference to Frank's example below... Frank W. Zammetti wrote: Let's say my bank's web site allows me to have a primary user account, and I can link to this account all my checking accounts and savings account to see them all in one dashboard display. I have to fill out a form to have an account added. The form has account number on it. Let's say one of the validations is to be sure the checksum of the entered account number matches one that would only be valid for me. It's a relatively simple math check, so it's done in validate() because really we're checking that the entered value is valid. Now, the Action behind it calls some DAO to add the account for me. But, it reasonably assumes that the data it gets in the form is valid. So, if validate() is not executed, I could conceivably enter an account number that isn't mine and have it attached to my user account and see its details. See I think that's a poor design. Why would you rely on a Struts validate method to handle that? For a financial application wouldn't you always be checking the account number vs the supposed user in Session scope somewhere in a non-Struts layer? The whole idea of component stuff is if later on you coded the front end in swing or flash that you would still have the security stuff ensured on the backend. I don't think letting a framework handle this type of security check is a good idea. I doubt too many people would say it's a wrong approach (we could of course argue architecture, that's always the case, but nothing stands out as patently wrong to me about this design). I'd say it's wrong from the standpoint that the backend should be checking this and throwing an exception. This whole thread is a perfect example why:) - don't assume the front-end is making things secure. Maybe later on you needed a flash front end they have other security concerns, at least if you code the backend part to make it's security check things are much better. (Granted someone might find a way to spoof a logged in user, but that's not what we are talking about here). I think the problem here though is that this is a fairly subtle thing, and something that could possibly be exploited in such a way that the request looks legitimate, and in fact is, as far as the filters and security checks go, but are not in terms of the logic of the application. Agreed that it probably should be handled better. My only argument is that I think it's level of a 'security' risk is pretty low, unless you are coding for security in your validate method, which I don't think is a good idea. I don't want to blow this out of proportion... I think the way most people architect their solutions, this probably wouldn't be a problem for most people. Agreed. But, even if we all agreed that it wasn't a security problem per se, it just logically does not make sense as far as I can see... if Struts is going to populate the
Re: Validation Security Hole?
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 when you post). Two minor comments below... Frank Laurie Harper wrote: [Moved to a top-level thread, as this doesn't have anything to do with (either of) the thread(s) it was nested in! :-)] Was it nested? I didn't even notice :) 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 preliminary thoughts in how to resolve the issue at the end of this post, though that discussion definitely ought to proceed on the dev list I guess. I'll re-post this message to the dev list later today if I haven't missed anything important below: * 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 * Consequence: any action which proceeds assuming that validation has completed successfully and which doesn't explicitly check isCanceled() is proceeding on a broken assumption * Questions: - why doesn't Struts call validate() on a cancelled request? If a request is canceled it usually means validations don't apply since the implication is that any user input will be thrown away. Users shouldn't be required to supply valid inputs for actions they are canceling. - why does Struts still call Action.execute() for a canceled request? Since you may still want to act on a canceled request (e.g. to clean up resources stored in the session). (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. - why does Struts still populate the action form on a cancelled request? If inputs are going to be thrown away anyway, why process them by populating the action form? [Commentary: I believe this behaviour makes sense since it preserves a standard way to access the request data, should you want to, regardless of whether the action was canceled. You could argue that either way...] I tend to agree with your commentary, even though I find it hard to envision a situation where you'd want to get at the parameters. Certainly better to be able to though. Here's my first thoughts on possible approaches to addressing the problem, to kick off further discussion on the dev list: - SAF1.2 and before: ? document, don't fix? add config req'm'ts on action mapping? Refer to discussion on user list for various options. - SAF1.3+: make cancel processing a command which you have to include in your request processing chain, and perhaps disclude it by default? [I'm not familiar enough with how you deploy chains on a per-action basis to know if this is the right way to do it...] I think this would be affected by what is done with 1.2... if it is modified to by default not allow Actions to be cancelable for instance, I would think it would be better to replicate that change into 1.3, which would likely entail changing the default chain. Open for discussion obviously :) - WW2/SAF2: implement cancel processing as an interceptor and either disclude it from default stack or require an action to implement an interface declaring that cancel processing should happen? L. - 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: Validation Security Hole?
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 for related events, and it makes it more difficult when you want to do things related to these events. To each his/her own I guess:) But, I believe Paul said this issue affects DispatchAction too... am I right Paul? Perhaps you could explain that part again? I'd rather not explain incorrectly if this is true. 3) Call the validation framework manually. I can give several reasons why this is a good idea and saves the developer a lot of headaches, but I've been over it before (happy to readdress if someone wants me to:). It's not much more code to write and actually simplifies things (very easy to see what's going on by simply looking at your Action class). 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? :) Anyway, that's my advice for anyone having trouble with Cancel issues. Oops, I guess you are :) I kind of assume you mean this with the qualification going forward. Many people use automatic validation and frankly love it, I doubt they would be in a rush to redo their existing apps. Let's say my bank's web site allows me to have a primary user account, and I can link to this account all my checking accounts and savings account to see them all in one dashboard display. I have to fill out a form to have an account added. The form has account number on it. Let's say one of the validations is to be sure the checksum of the entered account number matches one that would only be valid for me. It's a relatively simple math check, so it's done in validate() because really we're checking that the entered value is valid. Now, the Action behind it calls some DAO to add the account for me. But, it reasonably assumes that the data it gets in the form is valid. So, if validate() is not executed, I could conceivably enter an account number that isn't mine and have it attached to my user account and see its details. See I think that's a poor design. Why would you rely on a Struts validate method to handle that? For a financial application wouldn't you always be checking the account number vs the supposed user in Session scope somewhere in a non-Struts layer? I think your getting hung up on the design of the thought experiment rather than the underlying concept it's trying to demonstrate... yes, there are almost certainly better ways to implement such a function, but that doesn't mean what I outlined is an invalid approach... I can tell you from experience, I once wrote an app where you entered an account number and we had a validation to tell if it was valid based on nothing else but the account number. It's 100% an input validation... the user entered it, we need to know if it's valid, and we can determine that just by running it through some calculations. Now, what if there was some component to that validation that included the identity of the user, like in the theoretical app? Why would it suddenly not be a good idea to do that as part of input validation? Since I get request in validate(), I can get the info I need from session as you suggest, and therefore I can do everything I need to in validate(). Why would I incur the overhead of executing the Action, executing whatever business helper I have, maybe more, when I can do it all *before* any of that is hit? Again, I don't want to start debating whether your approach in terms of manually calling validate() is better or not because it doesn't ultimately matter in this context... many people don't do that, and expect that the framework will do it (which isn't completely unreasonable), and that's when this comes into play. The whole idea of component stuff is if later on you coded the front end in swing or flash that you would still have the security stuff ensured on the backend. I don't think letting a framework handle this type of security check is a good idea. That's a pretty good argument :) I'd say it's wrong from the standpoint that the backend should be checking this and throwing an exception. This whole thread is a perfect example why:) - don't assume the front-end is making things secure. Maybe later on you needed a flash front end they have other security concerns, at least if you code the backend part to make it's security check things are much better. (Granted someone might find a way to spoof a logged in user, but that's not what we are talking about here). You always run into questions about where the different tiers begin and end though. Besides, should an app throw an exception if I enter an invalid account number? If it
Re: Validation Security Hole?
(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 no implementation for cancelled(). The cancelled() is called but a return value of null indicates it is not implemented (bad design) and then proceeds on to the intended method. Since 99% of my MappingDispatchAction classes don't have any semantic necessity for canceling, I don't implement the method to return a forward, and thus the problem roars its ugly head. Laurie, I would like to see this fixed in 1.2; it is easier for me to drop in a patch than upgrade a whole library. Not many managers can buy total upgrades, but they can buy incremental patches. Paul __ 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: Validation Security Hole?
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.html.CANCEL' parameter to any request will cause automatic validation to be skipped, but the rest of the request processing / action invocation cycle to proceed normally __ 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]
Tiles question
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 === ... div class=crumb presentation:crumb key=tiles:getAsString name=crumbTitleKey/ link=%=(String)request.getAttribute(page) %/ /div ... In tiles-defs.xml == ... page 1 ... put name=crumbTitleKey value=crumbs.home / ... ... page 2 ... put name=crumbTitleKey value=crumbs.browse / ... Problem This doesn't work because I can't nest the tiles:getAsString tag within the presentation tag (or any other tag like c:set). Do you guys have any ideas on how I can accomplish what I'm trying to do here? Thanks. Aladin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tiles question
Aladin,
You cannot nest JSP tags inside JSP tag attributes. Split them up:
JSP 1.2:
tiles:useAttribute name=crumbTitleKey id=someid /
presentation:crumb key=%=someid% ../
JSP 2.0:
tiles:importAttribute name=crumbTitleKey /
presentation:crumb key=${crumbTitleKey} ../
Paul
__
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: Validation Security Hole?
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 stuff:) and I do see the problem Paul brought up and I do see how it could affect dispatch actions also if someone typed in the URL with canceled. But I don't see this as a 'big' security concern was my only point (More in a bit on that)... I think your getting hung up on the design of the thought experiment rather than the underlying concept it's trying to demonstrate... yes, there are almost certainly better ways to implement such a function, but that doesn't mean what I outlined is an invalid approach... 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 you see A B C links. Maybe if you are a super Admin you can see X Y Z. Now maybe link Y link calls /myAdminAction?someparam=1234 which is supposed to be an admin only action. How many developers assume that Well only admins are going to see this page with that link so I don't have to check in that Action if they have the correct role. I'm guessing a lot do, and depending on the app (intranet vs external), I might opt to let it slide. But the reality is there are plenty of times you can type in a URL (if you remember the URL from some day when you were an Admin) and you might be able to perform admin functions all from typing in URls. You'd probably say, that isn't a secure system. Well the same thing I see happening in this validate situation. If actual processing of the URL without going through validate is that much of a security risk, then I think you'd want to push that security check further back into the system. Like I mentioned earlier, maybe down the line someone is going to implement your front end in Flash or an Applet. Wouldn't you feel safer knowing that back end components aren't going to let anything really bad happen? I can tell you from experience, I once wrote an app where you entered an account number and we had a validation to tell if it was valid based on nothing else but the account number. It's 100% an input validation... the user entered it, we need to know if it's valid, and we can determine that just by running it through some calculations. Well, again, this is the kind of stuff I would never do in the validate method. You might like to do it there, but going way back to when I was first using Struts, it was always advised to NOT do this kind of calculation in the validate method. Would you do credit card validation there? I wouldn't. (Think of the mess that could happen in just this case if your Action assumed it passed credit card validation in order to ship a product and you bypassed the validate method by figuring out how to add the canceled param ot the URL). Now, what if there was some component to that validation that included the identity of the user, like in the theoretical app? Why would it suddenly not be a good idea to do that as part of input validation? Since I get request in validate(), I can get the info I need from session as you suggest, and therefore I can do everything I need to in validate(). Why would I incur the overhead of executing the Action, executing whatever business helper I have, maybe more, when I can do it all *before* any of that is hit? Because I don't think that's the place for this type of secure validation. I've always taken the advice that the form's validate method should ONLY check for proper structure of form entry elements - nothing more. All the big wigs back when I was first learning Struts said don't perform business-type checks in the validate method and that's what I think you are attempting to. To me that type of security check should ALWAYS be done deeper in the system and it's up to the backend/midtier guys to make sure that always gets checked. You obviously disagree on setting up the architecture that way which is fine. (Heck I could be way off, I'm just a code monkey - nuttin' more:). Again, I don't want to start debating whether your approach in terms of manually calling validate() is better or not because it doesn't ultimately matter in this context... many people don't do that, and expect that the framework will do it (which isn't completely unreasonable), and that's when this comes into play. You are correct, I probably shouldn't have brought up the manual validate thing, since in this context it's not that relevant so I apologize for that. I'm only now harping on the idea that the issue shouldn't be that big of a security concern since I don't think the Struts designers ever
Re: Validation Security Hole?
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 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: Tiles question
Thanks Paul.
Aladin
Paul Benedict wrote:
Aladin,
You cannot nest JSP tags inside JSP tag attributes. Split them up:
JSP 1.2:
tiles:useAttribute name=crumbTitleKey id=someid /
presentation:crumb key=%=someid% ../
JSP 2.0:
tiles:importAttribute name=crumbTitleKey /
presentation:crumb key=${crumbTitleKey} ../
Paul
__
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]
Re: Validation Security Hole?
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 scenario in a 'bad format' regard is the user will probably get some nasty error page back when the user tried to execute the action through a URL since the data wouldn't be in the correct format. Why do you care if this user that is mangling the url gets an error page? He/she was doing a no-no in the first place so they deserve the error page. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validation Security Hole?
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 exception handling, etc. Those kind of things I am very interested in preventing. Paul __ 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: bi-di messages and dir=RTL?
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 span dir=RTLhi there/span but then I can't escape any text and have to make sure I have escaped things in my messages. And I have a feeling this could get weird where some of the text on my page I am pulling from a database and have no idea what it's direction is. Is there a better way? Thanks - dave David Thielen www.windwardreports.com 303-499-2544 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: bi-di messages and dir=RTL?
David, I am not sure what the problem is. How is this any different than LTR text? You could use c:out escapeXml=false 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validation Security Hole?
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 you see A B C links. Maybe if you are a super Admin you can see X Y Z. Now maybe link Y link calls /myAdminAction?someparam=1234 which is supposed to be an admin only action. How many developers assume that Well only admins are going to see this page with that link so I don't have to check in that Action if they have the correct role. I'm guessing a lot do, and depending on the app (intranet vs external), I might opt to let it slide. But the reality is there are plenty of times you can type in a URL (if you remember the URL from some day when you were an Admin) and you might be able to perform admin functions all from typing in URls. You'd probably say, that isn't a secure system. Well the same thing I see happening in this validate situation. If actual processing of the URL without going through validate is that much of a security risk, then I think you'd want to push that security check further back into the system. Like I mentioned earlier, maybe down the line someone is going to implement your front end in Flash or an Applet. Wouldn't you feel safer knowing that back end components aren't going to let anything really bad happen? I don't disagree with any of that :) And yet... Once thing I remember from years ago when I was a bit of a hacker (not an especially good one, but still!) is that when you leave *any* hole, the good hackers will find a way to exploit it. It's almost as inevitable as taxes in this day and age. I agree, with all the discussion we've all had on this, I don't view it as a critical flaw either. But non-critical flaws have a nasty habit of becoming critical ones when a good hacker takes a lool :) Well, again, this is the kind of stuff I would never do in the validate method. You might like to do it there, but going way back to when I was first using Struts, it was always advised to NOT do this kind of calculation in the validate method. Would you do credit card validation there? I wouldn't. (Think of the mess that could happen in just this case if your Action assumed it passed credit card validation in order to ship a product and you bypassed the validate method by figuring out how to add the canceled param ot the URL). I think it's a very fine line between what is basic input validation and what is business rules. I think your right, this is probably a case where doing it in validate() wouldn't be the right answer because it probably is a business rule... but it is at least debatable. Your right, I wouldn't do credit card validation in validate() either, but what about a simple checksum to see if the credit card is even in a proper form? For instance, there is a formula to determine whether an CC # is a Visa, Master Card, Discover, etc. Is this really a business rule? You may argue it is, and that's not unreasonable, but I could argue it's just a simple input validation, and I think that's just as valid. I think unfortunately we've gone a little bit off-topic though, so we should probably both stop :) Because I don't think that's the place for this type of secure validation. I've always taken the advice that the form's validate method should ONLY check for proper structure of form entry elements - nothing more. Even though I said we should stop :) ... this is exactly my point from above. The determination of what is a check for proper structure and what is something more isn't clear-cut. All the big wigs back when I was first learning Struts said don't perform business-type checks in the validate method and that's what I think you are attempting to. To me that type of security check should ALWAYS be done deeper in the system and it's up to the backend/midtier guys to make sure that always gets checked. You obviously disagree on setting up the architecture that way which is fine. (Heck I could be way off, I'm just a code monkey - nuttin' more:). I don't disagree... but I don't think there is really a right and wrong answer. If you ask my *opinion*, yes, any non-trivial validation should be done at a lower level, absolutely. How you define non-trivial is the question :) I'm a code monkey too by the way, I just happen to be one that straddles the coder/architect fence a whole lot. My job entails a pretty equal dose of both these days. You are correct, I probably shouldn't have brought up the manual validate thing, since in this context it's not that relevant so I apologize for that. No need to apologize, not to me anyway :) It's not completely unrelated... I'm just not sure it really helps solve the problem at hand, not if we're trying to come up with a solution that will work for everyone that is.
RE: bi-di messages and dir=RTL?
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
span dir=RTLhi there/span but then I can't escape any
text and have to make sure I have escaped things in my messages.
And I have a feeling this could get weird where some of the
text on my page I am pulling from a database and have no idea
what it's direction is.
My solution is that I have a custom tag, and the internal processing code
looks something like this:
.rtlclass {font-family:David,arial;font-size:12px;direction:rtl}
if (isRTL(myStr)) {
out.append(span class='rtlclass'rlm;);
out.append(myStr);
out.append(rlm;/span);
}
public static final boolean isRTL(final String str) {
for (int i = 0; i 3; i++) {
if (str.length() == i)
return false;
Character.UnicodeBlock block = Character.UnicodeBlock.of(str.charAt(i));
if (block == Character.UnicodeBlock.ARABIC ||
block == Character.UnicodeBlock.ARABIC_PRESENTATION_FORMS_A ||
block == Character.UnicodeBlock.ARABIC_PRESENTATION_FORMS_B ||
block == Character.UnicodeBlock.HEBREW)
{
return true;
}
}
return false;
}
The rlm; on both sides is important because otherwise the browser *will*
screw up if you have punctuation at the end of the string.
Another thing to note is that, for some reason, all browsers tend to render
non-Latin fonts in a very teensy size. I don't know why. So it's a good
idea to have code to make sure that rtlclass has a bigger fontsize than you
would normally use.
Daniel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: hard question - Single Sign On
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/
RE: bi-di messages and dir=RTL?
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 span class=rtl.../span
PS: Good idea with the tag library extension.
Paul
__
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: hard question - Single Sign On
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/
--
=
The world will be ended if love is everywhere.
Shawzi
