[Esapi-dev] Internationalization (I18n) implementation for ESAPI (Java)

Wed Jun 1 09:22:26 EDT 2011

Please notice there are some guidelines for internationalization on Java
software, we developed for Softtek at OWASP Internationalization
project, I hope they help

https://www.owasp.org/index.php/OWASP_Internationalization_Java_Software

Regards,
Juan C Calderon

________________________________

From: esapi-dev-bounces at lists.owasp.org
[mailto:esapi-dev-bounces at lists.owasp.org] On Behalf Of Jim Manico
Sent: Tuesday, May 31, 2011 5:38 PM
To: Chris Schmidt
Cc: Tarcizio Vieira Neto; esapi-dev at lists.owasp.org
Subject: Re: [Esapi-dev] Internationalization (I18n) implementation for
ESAPI (Java)

> Furthermore, I think it would be worthwhile to also include contextual
Interpolators for the "built-in" validators [2]

Isn't this just part of the Java resource bundle/i18n standard? Let's
just use whats standard, no?

http://download.oracle.com/javase/tutorial/i18n/format/messageFormat.htm
l

- Jim

	CC'ing list for full disclosure :)

	Jim, I would generally agree with you in practice, but I think
making the validator compatible with the rest of the world should take
priority over pure OO design principles. [1]

	Furthermore, I think it would be worthwhile to also include
contextual Interpolators for the "built-in" validators [2]

	By doing so, integrating ESAPI Validators with Spring-Validator
and/or Hibernate-Validator is a relatively menial task. 

	Of course, this is still subject to the issue with no way to
canonicalize strings prior to validation [3] so go vote for that issue
while your at it! :)

	[1]
http://people.redhat.com/~ebernard/validation/#constraintsdefinitionimpl
ementation-constraintdefinition-parameters-message
<http://people.redhat.com/%7Eebernard/validation/#constraintsdefinitioni
mplementation-constraintdefinition-parameters-message> 
	[2]
http://people.redhat.com/~ebernard/validation/#validationapi-message
<http://people.redhat.com/%7Eebernard/validation/#validationapi-message>

	[3]
http://opensource.atlassian.com/projects/hibernate/browse/HV-473?page=co
m.atlassian.jira.plugin.system.issuetabpanels%3Aworklog-tabpanel

	On 5/31/2011 4:00 PM, Jim Manico wrote: 

		Yes, take this to list? Go for it...

		I agree with most of your design principles below. I
like it. The only thing I'm concerned about is:

		> I would much rather see the ValidationException take a
String that ESAPI first tried to resolve as a message, and if that came
back as null - the string itself is the message. 

		This is a violation of single responsibility principle
for function arguments. I'd rather see 2 different API's for clarity.
Earlier versions of the validator made this mistake around validation
content, and it bit us. This is a small point, Chris. Otherwise I'm with
you.

		- Jim

			Couple things:

			1) Any reason this isn't on list?

			2) Any solutions such as this one going forward
should be added as drop-in components. Especially when talking about
things like Localization. Problem is, if I have a webapp that i18n is a
concern in, chances are that I already have some solution in place. It
is a huge pain to manage messages in several different places, so I
should be able to *tell* ESAPI to use my existing solution if I have one
by using an adapter, or if I don't have one - I should be able to use
this *component* to make it happen. IMHO, this is the single biggest
problem with using ESAPI right now, the fact that things like logging,
messaging, authentication, authorization, and so forth are already in
place in most applications and wiring them together right now is no easy
task. If you take a look at some of the "contribs" that I have added so
far, you will see the real power of this model [1]. The ability to drop
in the ESAPI-Spring-Authenticator, update my ESAPI.properties and
spring-security-context.xml and things just work! That is huge for the
usability of ESAPI in existing apps, and this is the model that we need
to start going with (as opposed to bolting more on to the RI) going
forward. A solid RI is important, but I should be able to swap out RI
components easily with components that make sense for my application.

			3) In regards to this particular implementation,
overall I think it is solid - I would be wary of forcing the use of I18N
utils to users. As a matter of fact, while it should be "available" to
users, we should be enforcing the use of API methods in *all* cases as
opposed to exposing them to utility methods. 

			I would much rather see the ValidationException
take a String that ESAPI first tried to resolve as a message, and if
that came back as null - the string itself is the message. So you would
basically have 

			   throw new
ValidationException("Safefile.invalidDirectory",
"Safefile.directoryPathContainsIllegalCharacter", path, m1.group() );

			Which would resolve the
"SafeFile.invalidDirectory" and
"SafeFile.directoryPathContainsIllegalCharacter" messages from the
resource-bundle. Respectively:

			   throw new ValidationException("You messed
up!", "Illegal character in directory path", path, m1.group() );

			Would simple render the passed in messages
themselves since no resourcebundle would contain those as message keys. 

			This also aligns the ESAPI validator with the
JSR-303 specification a little closer, so that JSR-303 validation
entities can wrap ESAPI validators with little-to-no work.  !important

			[1]
http://code.google.com/p/owasp-esapi-java/wiki/esapi_contribs_spring_aut
henticator

			On 5/30/2011 10:56 PM, Jim Manico wrote: 

				i18n patch attached. Thoughts?

				Ok,

				Here is the patch and commit message. I
think that in 1 week I can finish all the messages.

				Regards,

				Tarcizio

				2011/5/25 Jim Manico
<jim.manico at owasp.org>

				I think for the first pass, we only need
translation for user messages? Perhaps?

				Id be happy to review your patches!

				Acceptable sir?

				Aloha and THANK YOU for all your
efforts! 

				Jim Manico

				On May 25, 2011, at 9:04 PM, Tarcizio
Vieira Neto <tarciziovn at gmail.com> wrote:

				To skipping the commit problem, I was
thinking in create a patch file and send it with the commit message for
who could commit the code for me.

				I'm requesting this because I need know
if every one agree with idea implemented in code for continue coding
effort and if someone in ESAPI comunity wants help me, they will have
the infraestructure to do it.

				Regards,

				Tarcizio

				I have an doubt: What may I do with
general exceptions? Translate message with the same Locale defined for
Logs messages throw 

				2011/5/24 Chris Schmidt
<chrisisbeef at gmail.com>

				Ill take a gander at it this afternoon

				Sent from my iPwn

				On May 24, 2011, at 9:03 AM, Tarcizio
Vieira Neto <tarciziovn at gmail.com> wrote:

				I'm trying commit the code and the SVN
returned the following message:

				svn: Commit failed (details follow):
				    svn: Commit failed (details follow):
				svn: MKACTIVITY of
'/svn/!svn/act/18e68522-3001-0010-9e59-d9005c8fb67d': 405 Method Not
Allowed (http://owasp-esapi-java.googlecode.com)
				svn: MKACTIVITY request failed on
'/svn/!svn/act/18e68522-3001-0010-9e59-d9005c8fb67d'

				If someone knows what is happening,
please tell me.

				Regards,

				Tarcizio

				2011/5/8 Jim Manico
<jim.manico at owasp.org>

				Gents, how do you like this plan for
ESAPI i18n?

				Jim Manico

				On May 3, 2011, at 4:37 PM, Tarcizio
Vieira Neto <tarciziovn at gmail.com> wrote:

				Hi,

				I'm finishing the I18n prototype class
to insert I18n pattern in all exception/error messages, so I would like
to expose the idea for discussion in the list.

				The requirements are: 
				* log messages must be stored in a
common language defined in ESAPI.properties 
				* user messages must be generated for
each user using Locale object retrieved with getLocale() method in User
interface.

				I created a class named I18nUtil and
should be stored in org.owasp.esapi.util

				The methods signature of I18nUtil class
are:

				public static String getLogMessage(final
String messageId, final Object... args)
				public static String
getUserMessage(final String messageId, final Object... args)
				public static String
getI18nMessage(final ResourceBundle messages, final String messageId,
final Object... args)

				The last method is reused by other
methods that set appropriate ResourceBundle for each context (log/user).
At first I thought set as private method, but I thought that would be
util for developpers who wants to create own messages in distinct files.

				The "Object... args" is variable
arguments that fill the message parameters for dynamic messages.

				In ESAPI.properties would be necessary
set the language used for all log operations and default language used
in case of getLocale() User method returns null or when doesn't have any
property file defined for the user locale, for example:

				(...)

#=======================================================================
====
				# ESAPI Internationalization
				Internationalization.logLang=en_US  -->
language used to Log messages
				Internationalization.defaultLang=en_US
--> default language used when the user language can't be retrieved.
				(...)

				For study case I used some classes from
ESAPI library that call for log methods and throw
EnterpriseSecurityException. Those classes are Base64.java and
AbstractAccessReferenceMap.java.

				Here an code example extracted from
Base64 class:
				* Old way:
				logger.error(Logger.SECURITY_FAILURE,
"Bad Base64 input character at " + i + ": " + source[i] + "(decimal)");

				* New way using I18nUtil:
				logger.error(Logger.SECURITY_FAILURE,
I18nUtil.getLogMessage("Base64.badInput", i, new Byte(source[i])));

				----------------------------------
				Here an code example extracted from
AbstractAccessReferenceMap class:
				* Old way:
				throw new AccessControlException("Access
denied.", "Request for incorrect type reference: " + indirectReference);

				* New way using I18nUtil:
				throw new
AccessControlException(I18nUtil.getUserMessage("AbstractAccessReferenceM
ap.accessDenied"),

I18nUtil.getLogMessage("AbstractAccessReferenceMap.incorrectTypeReferenc
e",indirectReference));

				The resource bundle message would be
stored in esapi folder and named with "esapi-i18n" prefix and
language_country suffix, for example:

				esapi/esapi-i18n_en_US.properties

				My idea is store messages IDs in
esapi-i18n_*.properties associating the messageID for each class name,
for example:

------------------------------------------------------------------------
--------------
				Base64.badInput = Bad Base64 input
character at {0,number,integer}: {1,number,integer} (decimal)
				AbstractAccessReferenceMap.accessDenied
= Access denied.

AbstractAccessReferenceMap.incorrectTypeReference = Request for
incorrect type reference: {0,number,integer} 
				(...)

------------------------------------------------------------------------
--------------
				I don't know if this is the better way
to associate message IDs in language config file. So I'm open to
suggestions.

				Would be great if we have a branch/tag
in SVN for colaborative work in this way.

				So, once we have a class support and a
pattern to follow, we can easily transform all messages with
internationalization support.

				References:

http://download.oracle.com/javase/tutorial/i18n/format/messageFormat.htm
l

http://download.oracle.com/javase/6/docs/api/java/util/ResourceBundle.ht
ml

				Regards,

				Tarcizio 

_______________________________________________
				Esapi-dev mailing list
				Esapi-dev at lists.owasp.org

https://lists.owasp.org/mailman/listinfo/esapi-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-dev/attachments/20110601/6f737865/attachment-0001.html 