Spring security doesn't work on Glassfish v3 - java

I have a java web application that use spring security for log in users, restriction access etc. , and it is working without problems on Glassfish 2.1, Tomcat, jetty, but on glassfish v3 doesn't work, when I try to login, and press button login, I'm getting login box from glassfish server(the box "The server xxxx requires user name and password").
Has somebody got such issue? Please let me know how I can solve this.
Thanks,
Iurie

Try to comment the following fragment:
<login-config>
<auth-method>BASIC</auth-method>
</login-config>
in ".../glassfish/domains/domain1/config/default-web.xml" file

I don't know what is causing this (and potentially it could be one of a number of things), but I suggest that you turn the logging level up to the max and see if that gives you some clues as to what is going on. (When the logging level is DEBUG or higher, SpringSecurity generates lots of logging.)
... the request is not sent to spring security, the glassfish stopped it with his basic authentication, the question is why.
I don't know what the cause of this is, but it sounds like some aspect of Glassfish authentication / authorization needs to be turned off if you want to use SpringSecurity. (Maybe you did this in your Glassfish 2.1 installation ...)
The way that SpringSecurity works, you will definitely see logging messages if a request goes to a servlet that has the SS filter chain in place. It is possible that there is a SS misconfiguration that means that you've not got the SS filter chain in place, but I suspect that the real problem is that Glassfish is doing its bit before the requests get sent to the filter chain.

Did you create a JDBC Connection pool and Resource in Glassfish server?
For ex:
User: root
Password: java
databaseName: theDatabase
serverName: localhost
portNumber: 3306
driverClass: com.mysql.jdbc.Driver
URL: jdbc:mysql://localhost:3306/dbname

The issue seems to be confusion over the /j_spring_security_check url, if you change it everything works again.
<security:form-login login-processing-url="/whatever_security_check" />
See this.

Related

Handle # character in spring web

I am trying to add an exception for security rules in Spring but getting 401 meaning my mapping is not recognized. The uri is /test/acc#v1=1&v2=2...
I have security configured:
http.authorizeExchange().pathMatchers("/test/acc*{v:.+}")
and
http.authorizeExchange().pathMatchers("/test/acc*")
And my controller annotation is:
#GetMapping("/test/acc{suffix:.+}")
None of it works, I keep on getting 401. Can someone help me out here?
It is a general consensus that Server does not receive the URL fragmentation details and it is applicable for all major servers java based servers like tomcat, jetty..etc please refer for more details

Strange behaviour of Tomcat 8.0.32: sometimes it ignores cookies. Can it be somehow debugged?

There is a very weird problem with our Tomcat 8.0.32 installed under Ubuntu 16.x.
This problem starts to happen accidentally and exists until tomcat server restart (so it is reproducible after it begins happen).
What happens, is that some of the requests send by timer from JS application with proper cookie: JSESSIONID= value are improperly processed: the Tomcat can not find Session object for it (from Spring MVC layer it means, that user is not authenticated). All requests with the same JSESSIONID being sent before this broken request, and all requests being send after (again with the same value of session id) - they all work fine!
We also certainly see that all headers in that request are correct (they are printed out by our application in some Filter), but Session object is not restored.
So basically it sounds like under some circumstances the Tomcat starts ignoring JSESSIONID from the requests sent via redirect from another server. And again, this does not happen always, only after some time of web-application life.
I will not provide any code here or configuration settings. First, because it looks like the poor Tomcat problem, second, because configuration is standard (out of the box after apt-install).
My question is: how can we configure the Tomcat in order to log all operations related to the JSESSIONID processing? Like that it finds session for the given ID, or does not and so on.
UPD: This never happens with more newer version of Tomcat 8.5.5. But due to some reasons it can not be updated on that particular server. My current goal is to collect evidences about this behaviour to be sure that it is a bug, or some strange default configuration that tomcat installation.
According to the docs https://tomcat.apache.org/tomcat-8.0-doc/logging.html
to enable debug logging for part of Tomcat's internals, you should configure both the appropriate logger(s) and the appropriate handler(s) to use the FINEST or ALL level. e.g.:
org.apache.catalina.session.level=ALL
java.util.logging.ConsoleHandler.level=ALL

Logout all still-logged-in users from WebApp using Shiro and Spring WebMVC (Java8, Spring 4.x)

I'm fairly new to shiro, so here's my question:
I've implemented Shiro into an application using Spring WebMVC / Spring Framework (4.x)on a Tomcat 8 container. The Roles and Permissions are working fine so far, the login, too, but Problem is, that sessions are still working when I redeploy my war-file / stop/restart the server, which is not intended here.
Would be great to get a hint what I have to do to implement something like an "auto-logout" of all logged-in users after a redeploy/restart of the server, e.g. redirecting to loginpage and showing a modal or s.th. saying "you've been logged out due to [reasons]".
Best regards,
Dominik
You can use the SessionDAO interface, but you need to do extra configuration to have shiro use a SessionDAO as described here:
http://shiro.apache.org/session-management.html#SessionManagement-SessionStorage
When you have configured it correctly you can do stuff like:
DefaultSecurityManager securityManager = (DefaultSecurityManager) SecurityUtils.getSecurityManager();
DefaultSessionManager sessionManager = (DefaultSessionManager) securityManager.getSessionManager();
Collection<Session> activeSessions = sessionManager.getSessionDAO().getActiveSessions();
for (Session session: activeSessions){
session.stop();
}
Only, if you want to have a message like you suggest, you cannot do this after you have removed the session as the server has no clue anymore if the browsers session was logged out.
Instead what you can do is write something to the db above where the session.stop(), i.e. set a flag that the next request should result in the autologout action, you could probably implement the autologout logic using a Filter.

Faces Servlet Application URL JSF/Glassfish

So I have let's say an application named MyApplication. I deploy it with a virtual server on glassfish and all is well since I set the default welcome page. Let's say the virtual server is to listen on mydomain.com
I goto mydomain.com and i see my index file of my application just fine. Then i go to do a j_security_check login.
And i am then redirected to: http://mydomain.com/MyApplication/page.xhtml
How can I get this to wehre it is: http://mydomain.com/page.xhtml ?
Now if I do take MyApplication out of the URL and try to manually goto that page it is blank, as I believe it is not being processed by JSF.
What I have tried.
* Setting the default glassfish application to my application and setting the context path of my application to / (glassfish complains and i cannot deploy my application)
* Doing the same as above without setting my context path to / and leaving it as is.
Will deploy but same issue.
My main reason for wanting this, is it seems if someone does get redirected to a path without the application name, the session state appears to be different. And causes some sporadic issues with session collision and values not being passed properly. So I either want to force the URLS to use the ApplicationName all the time, OR force them to not use it for the sake of consistancy.
There should be a way to accomplish this since I dont believe we should always have to have the ApplicationName in the URL.
Please help if you can, what I have found by searching seems to take care of it for the initial request but not when doing redirects using the FacesContext extenralContext redirect.
Unless I am not redirecting properly. I am at a loss here.
Thank you for the help.
IMHO you should consider using asap PrettyFaces
Your application URLs will always be elegantly displayed to your users.

Spring MVC application context path

My Spring MVC application is runnning on a Tomcat behind an Apache 2 acting as a proxy. I access my app directly in tomcat via an url like http://localhost:8080/myapp. I access my app via proxy with an url like http://localhost/tomcat/myapp.
The second url makes my app behave incorrectly, because it supposes it lives in /myapp context path, but via the proxy it should live in /tomcat/myapp.
Is there a variable in Spring or Servlet API, that holds /tomcat/myapp if I am accessing it via the proxy, and /myapp if I am accessing it directly?
Thanx
I think you need to enable proxy support then. This link might help you or give a little hint in this regards.
http://tomcat.apache.org/tomcat-6.0-doc/proxy-howto.html
Just stumbled upon this post while searching for the config setting for tomcat.
There is a much easier way to configure tomcat to handle the exact situation you are experiencing. See:
http://tomcat.apache.org/tomcat-5.5-doc/proxy-howto.html
Simple configure a connector for the proxy in tomcat, and the servlet/struts context path issues will resolve.
-edit: Obviously I didn't read #2 comment...
I mean when I redirect to "/index.jsp"
it actually redirects to
"http://localhost/myapp/index.jsp"
instead of
"http://localhost/tomcat/myapp/index.jsp"
Redirect to index.jsp instead of /index.jsp
When you redirect to /index.jsp this acts as an absolute url and it gets redirected to myapp/index.jsp. index.jsp is a relative url and will redirect to tomcat/myapp/index.jsp

Categories

Resources