Is there a way to set a context path in a Spring Boot application running in GCP AppEngine Standard?
I want to add an implicit prefix to all my resources. So if the #RestControllers are, say, /a and /b, I want that to access them, their URL is always /my/prefix/a and /my/prefix/b. In normal, embedded mode in Spring Boot, this works by setting server.servlet.context-path. However, this setting is not respected by AppEngine. In it, /my/prefix/a returns a 404 and I have to use /a instead
How do I add a common prefix to all my resources in AppEngine Standard? This seems basic for AppEngine's services/modules support to avoid duplicating the prefix in all controllers, but I can't find how to do it
so per my conversation with the Google Cloud Support team - I got confirmation that the App Engine Standard does not support / honor the port & context paths set in spring-boot.
This is the response I got from them:
"With regards to your concern about App Engine not honoring the manually set port number and context path, this is because it should be setup in yaml file.
For the port to be set as 7777, it should be done by port forwarding. However, port forwarding is only available in App Engine Flex. For more details about this, you may visit this page [1].
For the context-path, you may use the tag and include in appengine-web.xml file. This sets the path in your application that contains the static files. You may check this document [2] for more information.
You could also include the tag in your appengine-web.xml as it is also useful for serving static content such as images, CSS stylesheets or JavaScript files. You may use this reference [3].
With this solution or workaround, this also address that spring-boot application could be deployed in App Engine.
If you have further concerns, just let me know.
Thank you and have a nice day!
[1] https://cloud.google.com/appengine/docs/flexible/custom-runtimes/configuring-your-app-with-app-yaml#port_forwarding
[2] https://cloud.google.com/appengine/docs/standard/java/config/appref#public_root
[3] https://cloud.google.com/appengine/docs/standard/java/config/appref#static_files
"
However, setting the to some value did not still pick it up as the context path. So had to abandon GAE unfortunately. Wasted so much time on this - hope this is useful for others that are struggling with this.
Related
I have an application with Vaadin 8 and Spring Boot. Currently, I'm in progress of adding authentication to this app. So, I enabled Spring Security and started tinkering with it. Basically, I followed this tutorial: https://vaadin.com/tutorials/securing-your-app-with-spring-security/setting-up-spring-security
The approach, described there, works fine, however, I'm slightly disturbed by the fact that /VAADIN/** path needs to be publicly available (otherwise, Vaadin doesn't work). I mean, of course, I have protected particular pages by their paths (e.g. /admin) and unauthenticated users won't be able to open them, but isn't exposure of /VAADIN/** path dangerous? What if some hijacker tries to send some request to the Vaadin servlet outside of the UI (by simply curling it) with some specific headers/parameters? Is it possible that by formatting such request in some malicious way, the data will be actually returned to this hacker, bypassing Spring Security?
but isn't exposure of /VAADIN/** path dangerous
It is not dangerous per ce. The framework itself has just some generic parts there, like static resources for the client, like the widgetset and theme. Having said that, it is of course to be noted it application design. For example you should not put something that includes confidential info in your app as ThemeResource, but use ClassResource instead and things like that.
I have an application with name test.war.
Because of Apache installed on my server I have to use another port number for Tomcat applications so after deployment this application available at domain.com:8080/test/.
I decided to create a subdomain in order to remove that ugly 8080 from url, so I setted up the server like described here. So now test.domain.com reffers to domain.com:8080/test/.
Everything seems fine except of one problem - because my application is not ROOT.war and I am using spring:url function every url in the application is translated to /test/bla-bla. So I removed that function. But still have a problem with spring security because it still translates an urls relative to app name i.e. /test/bla-bla.
How can I solve that problem?
Thank you
UPD: I don't want to deploy it as a ROOT application because I have two or three such applications and I wanted to create a subdomain for each one of them
Spring Security doesn't "translate" URLs. In fact this isn't specific to Spring Security. You'll run into similar issues with any application which does redirects. If you want to hide the context paths of applications which are behind a proxy, then you need to rewrite the URLs at the proxy.
I'd recommend you read the Tomcat Generic Proxy Howto and the section on URL rewriting in particular, as it specifically addresses this issue.
My old way using mod_jk in apache and configure virtual host in tomcat
In the JSP file, I refer to CSS as below
/<%=request.getContextPath()%>/css/styles.css
while the home link is set to
/<%=request.getContextPath()%>/
so this worked fine when I use mod_jk in apache to work with tomcat using ajp;
When I try to configure reverse proxy as below
ProxyPass / http://localhost:800/mywebapp
ProxyPassReverse / http://localhost:800/mywebapp
the home page can be retrieved fine but the css request becomes
http://mydomain.com/mywebapp/mywebapp/css/style.css
so the css file can not be retrieved correctly;
I think one possible way is to always use relative path like ./style.css or ../style.css
a. since header/footer are shared, and the home page is in a different level with detail page, it's inconvenient to use relative path because they're at a different level
b. still, I think the home link will have to be /<%=request.getContextPath()%>/
so I wonder what's the way to set contextroot fine in java web and also work fine with reverse proxy?
thx a lot
As I know your application server (Tomcat) isn't able to be aware of a reverse proxy presence. Generally speaking, it can be contacted through any number of reverse proxies or directly by browsers. A network configuration is usually used to limit this, not HTTP or Java.
So, you must accurately rely on relative URLs to make your application work well.
When I have to deal with reverse proxy presence (almost always due to SSO architectures), I embed a "junction" configuration string item (the portion of the URL used in the proxy to map the application) and use it in the only places where I need to build an absolute URL.
I have a webapplication that I am running in Felix osgi container. I am using jetty as the implementation for the extHttpService. Currently it is writing the cookies to the '/' root path. I would like to change this as it is causing conflicts with other web applications. Looking at jetty documentation it appears I need to set the following property.
org.mortbay.jetty.servlet.SessionPath
However, I am unable to find a way to set this using the ExtHttpService via osgi. I have tried creating a jetty.xml file, adding this to the config.properties, and setting it as a property in the call to register my servlet.
Does anyone know how to set this?
thanks,
I actually ended up patching the source for my current implementation, but on the mailing lists here, a patch has been submitted that should allow this to be configurable.
In Java on WebSphere Application Server if I want my servlets, etc., to start with a certain root path, I use the context-root property in the EAR deployment descriptor (application.xml). For example, my servlet is named GetData, but I want the URL to be www.mysite.com/secure/restricted/GetData, so I set the context-root to secure/restricted.
How do I do that in ASP.NET on IIS? Is the some kind of configuration setting for the application?
One option would be Url Rewritting - http://weblogs.asp.net/scottgu/archive/2007/02/26/tip-trick-url-rewriting-with-asp-net.aspx
On the other hand, if you have your dynamic asp.net site separated from the rest of your content, you can add the folder secure/ and configure in there through the IIS Manager to point restricted to your asp.net site (regardless of where you have it stored).
That said, I don't know whether the WAS context-root give you something extra, for links to other info outside the asp.net site.
In .Net Core 2.0, there is an applicationUrl property in launchSettings.json:
By default, it will be "http://localhost:port/GetData" or "http://localhost:port"
Just change it to your final URL:
"http://localhost:port/secure/restricted/GetData"