External security system does not work with Vaadin

We have developed our system for about 4 years, it is based on Java servlet. Weeks ago, my colleague went to a Java conference and introduced Vaadin to me. We decided to start with a test page coded in VAADIN. We built the page and it works okay on development machine. However when we deploy to our TEST environment, it shows “communication problem” error message.

The TEST environment is behind an internal secuirty solution (https), which fetches user data when user opens the webpage and passes the information to application as session data. We can open the Vaadin page correctly if we open the direct URL link on TEST server, but we got the error message if we use the secuirty solution URL.

My hunch is that the security system conflicts with Vaadin when it changes sessions. Is there anyway to go around? Any suggestions? We are located in Finland.

Hi,

I had a similar problem. I break it down to the test scenario discussed in this thread:

http://vaadin.com/forum/-/message_boards/message/136778

Maybe that will help you too…

Regards, Thorsten

Hi Thorsten,

Thanks for your reply! I tried your solution:

	<servlet-mapping>
		<servlet-name>XXXApplication</servlet-name>
		<url-pattern>/test.do/*</url-pattern>
	</servlet-mapping>
	<servlet-mapping>
		<servlet-name>XXXApplication</servlet-name>
		<url-pattern>/VAADIN/*</url-pattern>
	</servlet-mapping>

But it doesn’t help. I think they are not similar problems. My problem is, let’s say our application server is
http://test-server/app/
and security server is
https://security-server/app
. We registered our application server url in security server so that when user visit
https://security-server/app/test.do
, it is forwarded to
http://test-server/app/test.do
with a package of user information in session data. This is forced to be used in all applications so we do not have a choice and no right to modify anything. The idea of the security solution is, users will be automaticalled identified when they open web browsers.

What is the name of securoty server software, a “Connectra” ?

If so, Connectra also rewrites Javascript in the filtered web pages, and have troubles with GWT apps. We have that problem with one of our clients and people from Connectra still researching this question (the have a full supporte contract wih them). So far I was not able to find a workaround.

If your security server works similar way (exposes some webapps from intranet) - it may use similar techique and same problems.

Have you tried to disable xsrf protection?

Try to add the following to servlet parameters


<init-param>
      <param-name>disable-xsrf-protection</param-name>
      <param-value>true</param-value>
    </init-param>

This might not help, but doesn’t take too much of your time to try it out.

Hi guys,

Thanks for your replies! This security solution is developed in another department in Norway, I guess it is developed internally and has a different name. I sent an email to them but no reply so far. I think it uses similar technique. I will try Joonas’s solution next Tue/Wed. Happy easter, everyone!

BR,
Xuan

Hi again,

I guess I may found the problem, but I need your expertise to help me.

My application is deployed to TEST server, the url is:

http://test-server/<APP_NAME>

the Vaadin page is:

http://test-server/<APP_NAME>/test/

the widget is located in

http://test-server/<APP_NAME>/VAADIN/widgetsets/xxxxx…

Test is fine and works.

However after the security portal wraps the TEST server, the url became:

http://security-server/<PORTAL_NAME>/<APP_NAME>

<PORTAL_NAME> is just one more level. However the VAADIN source code still shows:

src=“/<APP_NAME>/VAADIN/widgetset/xxxxxx”,
no wonder the application cannot be loaded correctly because there is no file in
http://security-server/<APP_NAME>,
but instead they should be in

http://security-server/<PORTAL_NAME>/<APP_NAME>

Okay now the question is, how can I modify the url generated by VAADIN to point to
http://security-server/<PORTAL_NAME>/<APP_NAME>

Thanks!
Br,
Xuan

Hi,

You can either a) use a static HTML startpage (basically copy the contents of the generated one, modify whatever needs to be modified) or b) extend/modify (Abstract)ApplicationServlet (remember to modify web.xml to use your version instead of the standard ApplicationServlet).

Best Regards,
Marc

(Sorry for the slow reply, I just got back fro my vacation :slight_smile: