I have been developed a jnlp file, and it is working properly when client downloads it from his/her browser. No problem up to here, but client can also access to the jar files that my jnlp is referencing, and eventually download them.
I don't want my jars to be downloaded by others by writing the path from browser. I just want to make the jnlp is directly accessible from browser.
How can I fix this situation ?
There is no 'fix' for it. If the Jars are accessible to the JWS client that launches the app., they are also available by direct fetch.
You can use the provided JnlpDownloadServlet as a way to block access. The JnlpDownloadServlet (look for it in the samples provided with the JDK) will handle requests for Jar files and do a diff on them. If you setup your web.xml file like
<servlet>
<servlet-name>JnlpDownloadServlet</servlet-name>
<servlet-class>com.sun.javaws.servlet.JnlpDownloadServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>JnlpDownloadServlet</servlet-name>
<url-pattern>/app/*</url-pattern>
</servlet-mapping>
then all requests for the files in /app will go through this servlet. This will prevent users from doing a simple browse to see the available files, but if they know the file name they can still create a get request to fetch it through the servlet.
If that is a problem, then you can also put security on access to this servlet (as you would any other servlet) using the security-constraint settings in the web.xml. If you add that, then the javaws launcher will require the user to provide valid credentials before it will download the files. I used BASIC as the auth-method because I wasn't sure if the javaws client would honor any others.
What if you generate the jnlp dynamically via a JSP or servlet (see here an example)?
In this case you can write a filter that can implement a policy(based on a cookie?) for retrieving files. If the cookie is not set you can disable the download of jars.
See the following article: http://lopica.sourceforge.net/faq.html#cookies
Related
I need to block the direct access to the jsp pages.
I've set my web.xml like this:
<security-constraint>
<web-resource-collection>
<web-resource-name>My Hidden Pages</web-resource-name>
<url-pattern>/*.jsp</url-pattern>
</web-resource-collection>
<auth-constraint></auth-constraint>
</security-constraint>
but all the pages are still accessible by typing their address in the browser address bar.
How can I solve this?
FYI I'm using jetty-maven-plugin and servlet-api 2.5
thanks
You don't hide jsps that way.
There are a few common approaches (best choice first)
Precompile your JSPs during build time, and don't include the actual JSP files in your WAR file.
Put your JSP file in the WEB-INF folder somewhere. Access to the jsps are then done via a Controller servlet. This uses the security of WEB-INF to prevent direct access to the JSP files, something that all servlet containers must honor.
See past stackoverflow questions on this:
Why put JSP in WEB-INF?
How can I hide the JSP file in WEB-INF folder?
There are many more, just search for "jsp in web-inf" to discover more about this concept.
Properly configure Jetty's JSP implementation. Once done, this means all access to JSP files like must go through the that implementation's JspServlet.
See webdefault.xml for example of how this mapping is defined.
If you see an error or warning on startup about "No JSP Support for ", then you know you've not configured JSP properly, and that means all JSP files will instead be served in a static way.
Note: If you are using an older version of Jetty (anything older than version 7.6.16), or as using an older version of Java (anything older than 1.7_40), or are using Jetty on Windows (problem here is solved with Jetty 9.3.0 due out in the next month or so), then even this can be worked around.
Your <url-pattern> is incorrect. It should be <url-pattern>*.jsp</url-pattern> without the /. The allowed patterns according to spec are:
A URL pattern is a URI that is relative to the application context.
Patterns can include:
Path mapping, starting with / and ending with /* This pattern identifies any resource that starts with a given path, for example,
/catalog/* or /catalog/products/*
Extension mapping, starting with *. This pattern identifies any resource with the given extension, for example, *.jsp or *.gif
Default servlet mapping, containing only / This pattern identifies the default servlet of the application.
Exact matches This pattern uses a string that represents a specific resource, for example, /snoop is a servlet mapping and
/list/banner.jsp is a file mapping.
If you want to secure pages in given folder you need to use pattern like /folder/* , if you want to protect all pages use just *.jsp, if you want to protect all pages except index.jsp, you will need to add another constraint which allows explicitly access to the /index.jsp file.
In my web based application (Tomcat7 / JDK 7 - JSP 3.0), I built a translator to take csv files, clean them up, and save the file off. A second part then parses the file for certain information and creates a second file (so it can be loaded into another system for verification). This happens every day. These files are being written to ${ECLIPSE_HOME} (because I'm running this in Eclipse).
What I want to do is have a folder created in the application's root directory {i.e, [app-root]/toBeDLd} specifically for saving the generated files into and downloading them, have my front end JSP be able to read and display the files (like a list of downloadable files, you click the link it downloads in your web browser) and at a specific time, delete all the files in that directory. I don't need to keep them, or have a backup of them.
From what I have read, Sending OutputStream to browser and let browser save it would be a decent starting point, but I have also read some other comments on SO that it is a violation of servlet spec to save files inside of the web app directory. I'm not sure if that is due to it being the root of the webapp or not though. Ideally I would like to keep this completely contained within the web application.
Is this possible? Is this the best way to do this?
Dont put it anywhere under Tomcats webapps. This is probably a very bad idea.
My Suggestion is to add a dataDir init parameter to you web.xml:
<servlet>
<servlet-name>MyServlet</servlet-name>
<servlet-class>com.example.MyServlet</servlet-class>
<init-param>
<param-name>dataDir</param-name>
<param-value>/var/data</param-value>
</init-param>
</servlet>
You can then use this parameter inside your servlet:
getServletConfig().getInitParameter("dataDir");
If you want it compact with your Tomcat maybe choose $CatalinaBase/dataDir
Whoever deploys the Servlet now can decide where to put the Data.
Maybe an extra partition without execute rights. Maybe an extra fast partition.
Would it work to setup some filters using Spring 3 MVC where the paths for javascript files and css files are modified when streamed to the client, by embedding some timestamp in the filename. And then when those resources are later requested another filter then strips those timestamps out?
This would be an attempt to prevent problems of cached js/css files when an application is redeployed
What would I need to do to set this up? How do I setup the filter to replace the paths with a timestamp and then how to I setup the filter to later strp the timestamps out?
I just need info on the Spring 3 MVC configuration for it in the web.xml, I am ok with what the actual code in the filter will need to do
It may be simpler to use Spring's resource mapping <mvc:resources>, that maps a virtual path to the real location of your CSS and Javascript files. The virtual path can contain the version of your application. This means that when you deploy a new version of your application, the path of the CSS and Javascript that gets sent to the browser is different than before and this fools the browser into thinking that they're new resources - and so it reloads them.
For example to map CSS and Javascript files in /resources:
<mvc:resources location="/resources" mapping="/resources-1.2.0/**"/>
This says that any request that comes in with the URL pattern /resources-1.2.0 followed by anything (e.g. /resources-1.2.0/css/styles.css), look for the file in the folder named resources in the web root.
When you update the application version between deployments the virtual path to the CSS and Javascript resources will change and so browsers will be forced to reload the files - even though the real files are in the same old location.
You can make the application version dynamic too - so you don't need to modify your config file.
There's a more in-depth write up of this whole approach here.
How is it possible to restrict files(PDF) access in JSP/Glassfish so they can be opened only from a source code not with a straight url. For PHP projects I used .htaccess.
Anything under the webapp's WEB-INF directory cannot be accessed via direct URL, but application code can access it. This is a good place to put internal resources, config, JSPs, etc.
Wow,
.htaccess is an Apache HTTPD feature. As far as I know there isn't anything comparable in GlassFish. What you could do is: Write a Servlet or Servlet Filter which takes care of this and/or map the *.pdf extension in web.xml to it..
Thanks,
M
I have written a facelets web application using tomcat as a application server. My program has a foobar.xhtml and the URL to it is:
http://localhost:8080/Myapplication/foobar.faces
Can I change something in my application so that a link to:
http://localhost:8080/Myapplication/
..will actually render my application on http://localhost:8080/Myapplication/foobar.faces ?
Alternatively, could the http://localhost:8080/Myapplication/ be redirected to http://localhost:8080/Myapplication/foobar.faces ?
You would normally use the <welcome-file> entry in the web.xml for this. But unfortunately this doesn't work as expected on at least Tomcat when using fictive URL's which are to be passed through a servlet like a FacesServlet. Tomcat will scan for the physical file on the disk matching the exact name before forwarding. If it isn't present, then you will just face a default 404 error page.
Using /foobar.xhtml as <welcome-file> is also not going to work since that page requires to be parsed by the FacesServlet to get all the JSF stuff to work.
One of the ways to fix this is to place another real /foobar.faces file there next to the real /foobar.xhtml file. It doesn't need to be filled with code, it can be left empty. Just the presence of the physical file is enough for Tomcat to open the desired page as welcome page.
web.xml has a
<welcome-file-list>
<welcome-file>foobar.faces</welcome-file>
</welcome-file-list>
element where you can define the page to be opened.