I'd like to know if there is a way to provide login support fora all web application content. I mean when user tries to access some site (also static content - html), and he isn't logged or session expires he should be redirected to login site.
Html filter in web.xml for logging is almost what I need, but I also need authentication of html pages.
<filter>
<filter-name>AuthenticationFilter</filter-name>
<filter-class>example.AuthenticationFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>AuthenticationFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
This doesn't work with html pages, only servlet requests.
This should be generic mechanism, not like i.e. writing in every servlet session checking.
Thanks for all resopnes.
There are standard web.xml configuration options for defining this.
You shouldn't have to define a custom filter.
See http://download.oracle.com/docs/cd/B31017_01/web.1013/b28967/adding_security003.htm
If your application contains pages that require a user to be authenticated against a data store in order to be accessed, you must declare the following in the web.xml configuration file:
<security-role> defines valid roles in the security context.
<login-config> defines the protocol for authentication, for example form-based or HTTPS.
<security-constraint> defines the resources specified by URL patterns and HTTP methods that can be accessed only by authorized users or roles.
<servlet> defines the servlet that provides authentication.
<servlet-mapping> maps the servlet to a URL pattern.
defines the filter used to transform the content of the authentication request.
<filter-mapping> maps the filter to the file extensions used by the application. For details about the ADF binding filter, see Configuring the ADF Binding Filter.
Related
I want to connect servlet using urlconnection in wicket-spring integration, but when i try to hit the url its redirecting to webapplication page, So can anyone tell me how to connect servlet methods by using filters or any other way, so that i can directly hit dopost or doget methods.
The question is not very clear, so I'll try to guess. I suppose that you have a Wicket filter that intercepts and handles all the requests. Also you have some servlet, and you want requests to that servlet to not be intercepted by Wicket filter.
If this is what you want, here is what you can do to achieve this.
Let's say you have Wicket filter mapped to / and the servlet mapped to /my-service. Then you could tell Wicket filter to ignore requests to /my-service url:
<filter>
<filter-name>wicket.filter</filter-name>
<filter-class>org.apache.wicket.protocol.http.WicketFilter</filter-class>
<init-param>
<param-name>applicationClassName</param-name>
<param-value>... some application class name ...</param-value>
</init-param>
<init-param>
<param-name>ignorePaths</param-name>
<param-value>/my-service</param-value>
</init-param>
</filter>
If you want several paths to be ignored, you can separate them with commas like this:
<init-param>
<param-name>ignorePaths</param-name>
<param-value>/my-service,/my-other-service</param-value>
</init-param>
With this configuration, Wicket will ignore any requests under /my-service (that is, /my-service, /my-service/blabla and so on) and any request under /my-other-service.
Developed on ADF 11.1.2.4 (JSF2.0 -GF 3.1.2)
Expecting to implement urlrewrite for pretty urls.
Added into web.xml:
<filter>
<filter-name>UrlRewriteFilter</filter-name>
<filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
<init-param>
<param-name>logLevel</param-name>
<param-value>WARN</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>UrlRewriteFilter</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
<dispatcher>FORWARD</dispatcher>
</filter-mapping>
created urlrewrite.xml such as
<rule>
<from casesensitive="false">myTest</from>
<use-context>true</use-context>
<to>/faces/admin/admin.jspx</to>
</rule>
admin.jspx contains TF.
When i deploy project and request hostname:9999/mytest redirects right page(hostname:9999/faces/admin/admin.jspx) and page renders without problem. But my actual goal was that making supply to see never real url. But i can see the real url on browser such as:(...jspx?_adf.ctrl-state=4avl71cil_1) So, what am i missing? By the way; When i type the masked url, it redirects my real page, so it works good. But seems to be the real url on browser address bar. If i only use html pages out of 'faces' context, then urlrewrite works as fully expected.
Thx, brgds
As you have Tucky URL Rewriting filter, ADF comes with its JSF View Handler, and before ADF 12.1.x you won't be able to forward URLs unless you are using Apache Server Rewrites or Oracle HTTP Server, as the ADF internal filter will look for _adf.ctrl-state and if it's not found it'll append it to the URL which will show the actual URL of the page.
You can try to hack those _adf.ctrl-state by extending ServletRequest and when asked about _adf.ctrl-state to provide the last value saved in session, but I assure you it'll be very harmful for the application.
We have been using Spring Security with our application for a few years now. Last week we upgraded Spring Security from version 3.1.4 to 3.2.0. The upgrade went fine and we did not find any errors post the upgrade.
While looking through the Spring Security 3.2.0 documentation we came across the newly added features around CSRF protection and security headers. We followed the instructions in the Spring Security 3.2.0 documentation to enable CSRF protection for our protected resources. It works fine for regular forms but does not work for multipart forms in our application. On form submission, CsrfFilter throws an Access Denied error citing the absence of a CSRF token in the request (determined through DEBUG logs). We have tried using the first option suggested in the Spring Security documentation for making CSRF protection work with multipart forms. We do not want to use the second suggested option as it leaks CSRF tokens through the URLs and poses a security risk.
The relevant part of our configuration based on the documentation is available as a Gist on Github. We are using Spring version 4.0.0.
Note that we have already tried the following variations without success:
Not declaring the MultipartFilter in web.xml.
Not setting the resolver bean name for the MultipartFilter in web.xml.
Using the default resolver bean name filterMultipartResolver in webContext.xml.
UPDATE: I have confirmed that the documented behaviour does not work even with a single page sample app. Can anyone confirm that the documented behaviour works as expected? Is there an example working application that can be used?
I was able to resolve this with help from the Spring Security team. I have updated the Gist to reflect a working configuration. I had to follow the steps given below in order to get everything to work as expected.
1. Common Step
Add a MultipartFilter to web.xml as described in the answer by #holmis83, ensuring that it is added before the Spring Security configuration:
<filter>
<display-name>springMultipartFilter</display-name>
<filter-name>springMultipartFilter</filter-name>
<filter-class>org.springframework.web.multipart.support.MultipartFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>springMultipartFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter>
<display-name>springSecurityFilterChain</display-name>
<filter-name>springSecurityFilterChain</filter-name>
<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
<filter-name>springSecurityFilterChain</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>ERROR</dispatcher>
<dispatcher>FORWARD</dispatcher>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
2.1. Using Apache Commons Multipart Resolver
Ensure that there is an Apache Commons Multipart Resolver bean named filterMultipartResolver in the root Spring application context. I will stress this again, make sure that the Multipart Resolver is declared in the root Spring Context (usually called applicationContext.xml). For example,
web.xml
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
classpath*:springWebMultipartContext.xml
</param-value>
</context-param>
springWebMultipartContext.xml
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean id="filterMultipartResolver" class="org.springframework.web.multipart.commons.CommonsMultipartResolver">
<property name="maxUploadSize" value="100000000" />
</bean>
</beans>
Make sure that the bean is called filterMultipartResolver as any other bean name is not picked up by MultipartFilter configured in web.xml. My initial configuration was not working because this bean was named multipartResolver. I even tried passing the bean name to MultipartFilter using web.xml init-param but that did not work either.
2.2. Using Tomcat Multipart support
Tomcat 7.0+ has in-built multipart support, but it has to be explicitly enabled. Either change the global Tomcat context.xml file as follows or include a local context.xml file in your WAR file for this support to work without making any other changes to your application.
<Context allowCasualMultipartParsing="true">
...
</Context>
After these changes using Apache Commons Multipart Resolver our application is working so far on Tomcat, Jetty and Weblogic.
This part:
<filter-mapping>
<filter-name>multipartFilter</filter-name>
<servlet-name>/*</servlet-name>
</filter-mapping>
Should be:
<filter-mapping>
<filter-name>multipartFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
It is an error in Spring Security 3.2.0 documentation. The bug has been reported and will be fixed in upcoming version.
After struggling with this issue a bit, I found a much easier solution by just using the Request Header defined in Spring Security instead of trying to get the CSRF token embedded as a part of the multipart content.
Here is a simple way I setup the header using an AJAX library for file upload in my jsp:
var uploader = new AjaxUpload({
url: '/file/upload',
name: 'uploadfile',
multipart: true,
customHeaders: { '${_csrf.headerName}': '${_csrf.token}' },
...
onComplete: function(filename, response) {
...
},
onError: function( filename, type, status, response ) {
...
}
});
Which in turn sent the multipart request with header:
X-CSRF-TOKEN: abcdef01-2345-6789-abcd-ef0123456789
Their recommendations for embedding into <meta /> tags in the header would also work just fine by halting the request on submit, adding the header via javascript, and then finish submitting:
<html>
<head>
<meta name="_csrf" content="${_csrf.token}"/>
<!-- default header name is X-CSRF-TOKEN -->
<meta name="_csrf_header" content="${_csrf.headerName}"/>
<!-- ... -->
</head>
<body>
<!-- ... -->
<script>
var token = $("meta[name='_csrf']").attr("content");
var header = $("meta[name='_csrf_header']").attr("content");
// Do whatever with values
</script>
</body>
</html>
More info: Spring Security - CSRF for AJAX and JSON Requests
Find most answer is answered server years ago.
If you need
Passing CSRF tokens with RestTemplate
This blog is quite enlightening https://cloudnative.tips/passing-csrf-tokens-with-resttemplate-736b336a6cf6
In Spring Security 5.0.7.RELEASE
https://docs.spring.io/spring-security/site/docs/current/reference/html/csrf.html#csrf-multipart
There are two options to using CSRF protection with
multipart/form-data. Each option has its tradeoffs.
-Placing MultipartFilter before Spring Security
-Include CSRF token in
action
For short, the first option is safer, the latter is easier.
Specifying the MultipartFilter before the Spring Security filter
means that there is no authorization for invoking the MultipartFilter
which means anyone can place temporary files on your server. However,
only authorized users will be able to submit a File that is processed
by your application. In general, this is the recommended approach
because the temporary file upload should have a negligible impact on
most servers.
To ensure MultipartFilter is specified before the Spring Security
filter with java configuration, users can override
beforeSpringSecurityFilterChain as shown below:
public class SecurityApplicationInitializer extends AbstractSecurityWebApplicationInitializer {
#Override
protected void beforeSpringSecurityFilterChain(ServletContext servletContext) {
insertFilters(servletContext, new MultipartFilter());
}
}
To ensure MultipartFilter is specified before the Spring Security
filter with XML configuration, users can ensure the
element of the MultipartFilter is placed before the
springSecurityFilterChain within the web.xml as shown below:
<filter>
<filter-name>MultipartFilter</filter-name>
<filter-class>org.springframework.web.multipart.support.MultipartFilter</filter-class>
</filter>
<filter>
<filter-name>springSecurityFilterChain</filter-name>
<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
<filter-name>MultipartFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>springSecurityFilterChain</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Another option
If allowing unauthorized users to upload temporary files is not
acceptable, an alternative is to place the MultipartFilter after the
Spring Security filter and include the CSRF as a query parameter in
the action attribute of the form. An example with a jsp is shown below
<form action="./upload?${_csrf.parameterName}=${_csrf.token}" method="post" enctype="multipart/form-data">
The disadvantage to this approach is that query parameters can be
leaked. More genearlly, it is considered best practice to place
sensitive data within the body or headers to ensure it is not leaked.
I am learning Spring MVC .
To configure servlet mapping in web.xml.
Who can tell what's difference between them
<servlet-name>login</servlet-name>
<url-pattern>/login/</url-pattern>
<servlet-name>login</servlet-name>
<url-pattern>/login</url-pattern>
<servlet-name>login</servlet-name>
<url-pattern>/</url-pattern>
<servlet-name>login</servlet-name>
<url-pattern>/*</url-pattern>
<servlet-name>login</servlet-name>
<url-pattern>/*.do</url-pattern>
Maybe more...
It is really necessary for me to know ,so that a new servlet will not be Intercept by other ones.
<servlet-name>login</servlet-name>
<url-pattern>/login</url-pattern>
This is exact url pattern, this servlet will be invoked only if the url is like someThing.com/login
<servlet-name>login</servlet-name>
<url-pattern>/*</url-pattern>
This is directory url pattern. So /someString or /someOtherString or /some/someOther will invoke the same login servlet.
<servlet-name>login</servlet-name>
<url-pattern>/*.do</url-pattern>
This is extension url pattern. Anything that is suffixed as .do will map to this. e.g. /someUrl.do or /some/someOther.do will invoke the login servlet.
this looks rather strange,you have this
<servlet-name>login</servlet-name>
<url-pattern>/*</url-pattern>
and thats all you need, the rest of the mapping are supercilious. But calling your spring servlet login is a bit weird. Normally you would call it spring-servlet or similar, everything is then mapped to that servlet, and specific request mappings are handled by different controllers - you can use RequestMappign annoation on controller methods.
I need to log in with j_spring_security_check using special characters in the username and/or in the password via url
http://localhost:8080/appname/j_spring_security_check?j_username=username&j_password=üüü
isn't working and
http://localhost:8080/appname/j_spring_security_check?j_username=username&j_password=%c3%bc%c3%bc%c3%bc
(with "üüü" urlencoded)
isn't working either
Any suggestion? Let me know if you need to see any other configuration.
Thanks
The Java Servlet standard is lamentably poor at supporting Unicode. The default of ISO-8859-1 is useless and there is still no cross-container-compatible means of configuring it to something else.
The filter method in matteosilv's answer works for request bodies. For parameters in the URL, you have to use container-specific options. For example in Tomcat, set URIEncoding on the <Connector> in server.xml; in Glassfish it's <parameter-encoding> in glassfish-web.xml.
(If you have to work in a fully cross-container-compatible manner you end up having to write your own implementation of getParameter(), which is sad indeed. Bad Servlet.)
However in any case it is a bad idea to pass login form fields in GET URL parameters.
This is firstly because a login causes a state-change to occur, so it is not "idempotent". This makes GET an unsuitable method and causes a load of practical problems like potentially logging you in when you navigate a page, or failing to log you in due to caching, and so on.
Secondly there are a range of ways URLs can 'leak', including referrer tracking, logging, proxies and browser history retention. Consequently you should never put any sensitive data such as a password in a URL, including in GET form submissions.
I'd suggest using a POST form submission instead, together with the CharacterEncodingFilter.
Maybe an encodingFilter in the web.xml file could be helpful:
<filter>
<filter-name>encodingFilter</filter-name>
<filter-class>
org.springframework.web.filter.CharacterEncodingFilter
</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
<init-param>
<param-name>forceEncoding</param-name>
<param-value>true</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>encodingFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
source: Spring security: Form login special characters
The issue was actually solved for me by moving the CharacterEncodingFilter ABOVE the SpringSecurityFilterChain in web.xml.