Darren Edwards

Tim Holloway wrote:I don't think it's likely to be worth the expense and trouble to write your own client-side proxy.

The plan is that this would be an extra software component and completely separate from the main application. It would only be created if time/budget permitted.

It'd be naive to think this proxy would never need updating, so a customer would still actually need to perform a software update. This would be very simple though, considering there is no DB associated with it. I'm a little undecided on the acceptability, but I have already created a framework that would allow automated updates (assuming an internet connection) without intervention from the customer.

Since using webex style remoting tools, customer support has become easier, but not all customers are keen on it. It'd be a big plus to have 90% of the changes made on a local server than trying to guide a customer through doing it on their setup.

In summary, I still like the idea - who wouldn't, it's technically quite cool I'll dig into a true java proxy server (like OWASP proxy) and see how much of the code I can make use of. I may have a fiddle doing it manually with HttpClient as well, although this is all going to be reconnaissance at the moment - the project may get rejected when I report an estimated cost with too may 0's on it!

Not completely sure which section to ask this question in, thought I'd try the tomcat section first!

I have a reasonably complex web application deployed and running in tomcat. The application is designed to handle multiple customers/sites, so instead of deploying the single application at each customer/site I would like to keep a single install (plus database) under my control. This has advantages in terms of support, upgrades, backups, monitoring, etc ..

If a customer is no longer going to get the actual application, they will need some kind of proxy application. They can't just access the application I host directly as some customers need input from their own environment, e.g. authentication via internal LDAP server. I need to decide on an implementation that allows the following.

* Allow a customer to visit http://internal-ip.com/myapp/listCourses.do and have the proxy transparently return a web page from http://external-ip.com/myapp/listCourses.do
* Allow the proxy to authenticate the users locally (via internal LDAP server)
* Allow the proxy to cache and serve some content locally, e.g. a large video file would be downloaded once, then served from the proxy.
* Allow the web application structure to change (move pages) without having to update the proxy application, e.g. no hardcoded URL mappings on the proxy. Proxy is as generic as possible and would be able to proxy any web application.

My initial ideas for implementation involve writing a web application, deployed in tomcat/jetty. When a HTTP request comes in, its path is examined to check if a local action is required (e.g. authentication). If not, use a package like Apache HttpClient to make a request to the server run by me. What I don't really like about this implementation is the manual cookie management between the proxy server and the server I run, but I'm not sure how to avoid it.

Alternatively, a java proxy server is hardly a new concept. I don't have much experience with open source java proxies that I could utilise/modify to achieve this. Any pointers to software others have experience with, gratefully received

CUSTOMER -------> PROXY SERVER --------> REMOTE SERVER

I agree with Antonio.

Although the exams don't really overlap, EJB are normally used by servlets, rather than thick clients. Having a good understand of the web container (SCWCD) may help you understand some of the SCBCD exam concepts.

After SCWCD and SCBCD you could think about SCDJWS to expand your knowledge on a topic touched upon in the SCBCD exam.

For me, the logical order is SCJP, SCJD, SCWCD, SCBCD, SCDJWS, SCEA. You could miss out SCJD if you have some general design experience though.

I should search harder, same question asked not long ago!

https://coderanch.com/t/163832/java-EJB-SCBCD/certification/boodk-HFEJB

Still a good book if you want to know the specs for EJB 2.0, but mainly a doorstop for me

Like many others I own Head First EJB and am looking to sit the SCBCD 5 exam which is based around the EJB 3.0 specification. Are there any sections of the book that are worth reading (no change from EJB 2.0 -> EJB 3.0) before I can purchase one of the other recommended books, or is it a expensive doorstop now?

Originally posted by Bear Bibeault:
Since the mesasges are coming from a properties file rather than user input, why are you thinking that they are vulnerable to an XSS attack?

Because the message in question is parameterised

myPage.text.title={0} Registration

and {0} is replaced by an object who's name attribute can be updated by a user. Perhaps it would have been clearer if I hadn't of tried to generalise the question so much. In my case the object is a course (as in a training course) and the JSTL section to i18n is

<h1><c:out value="${course.name}"/> Registration</h1>

To elaborate on the problem:

c:out does xml escaping by default, which helps protect my application from cross site scripting vulnerabilities, i.e. a user changes the name of object to <script>alert('xss');</script>

When i18n my application I don't want to lose that feature and use
<fmt:message value="myPage.text.title"><fmt:param value="${object.name}"/></fmt:message>

I tried the following, but it's invalid.
<fmt:param value="<c:out value="${object.name}"/>"/>

Which is why I went for the solution with c:set, just it seems a bit clunky.

Assuming the following is valid, it will be a more readable solution, so thanks.
<fmt:param value="${fn:escapeXml(object.name)}"/>
[ October 06, 2007: Message edited by: Darren Edwards ]

EDIT: in the middle of typing this message a solution dawned on me, but there may be a slicker way?

I'm doing some i18n work and I have

<h1><c:out value="${object.name}"/> Registration</h1>

The localised message file for english contains

myPage.text.title={0} Registration

I want to keep the HTML escaping as performed by c:out, but I'm not sure how to do it.

EDIT: working solution
<h1><c:set var="name"><c:out value="${object.name}"/></c:set><fmt:message value="myPage.text.title"><fmt:param value="${name}"/></fmt:message></h1>

HTTP transfers data using parameters you cannot do anything to alter that. What you can do is pass XML as a parameter if that's what you need.

http://sample.com/myapp?param1=<root><param name="a" value="b"/></root> String xml = request.getParameter("param1");
(in real life that parameter would be encoded, but I've not shown that for clarity)

By using debug statements in your filter have you established if it is being called? (simple System.out.println(..) statements will write to /logs/catalina.out in tomcat).

I'm not familiar with struts configuration, but it seems as though your filter is not being used.

As an aside - if you are using this to clean invalid data from request parameters it is not a good solution. What happens if some user data actually requires the user to enter trailing whitespace or < > characters? You should be able to setup validation (within struts) on your user data to make sure it does not contain invalid characters. Also make sure you escape user data when displaying it back to the user; use of <c ut value="blah" /> will automatically escape html entities.

You have to decide who's fault it is.

If the user entered invalid parameters you should tell them which ones were invalid and ask them to correct them.

If there is an error at the server (maybe IOException) all you can do is show the user a friendly error message like "Unable to create report, please try again later".

I wanted the session id to be created based on the clien't ip address.

That's not the way it works because it is flawed. Imagine you were working in a company with 500 employees - you all sit behind the company router and from the 'internet' all have the same external IP address. A session is a way to uniquely identify one client.

The SSL session id is not really suitable for web session tracking as SSL is a large overhead on the server. For that reason developers normally make use of SSL only on particular pages - your SSL session id would not always be available.

Your requirement is quite strange, perhaps you can explain why you need it so alternative approaches can be suggested.

Creating a wrapper around the request is the correct way to go, now you just need to override
public String getParameter(String name)
to return your trimmed and < > removed parameters.

You can never replace the original request parameters, you just use a wrapper class to pass back different parameter values.

I don't believe there are many mind readers on these forums, so perhaps you can explain what (and how) you've tried and what didn't work as expected ....

<c:when test="${viewRowsad[0]=='null'}">
If you are checking for a null you should not be wrapping it in ' ' (that treats it as a String).

Am not 100% certain without testing myself, but I think you can also say
<c:when test="${empty viewRowsad}">