I have been trying to maintain user session in a standalone JAX-WS client. The server code is as explained in https://weblogs.java.net/blog/ramapulavarthi/archive/2006/06/maintaining_ses.html.
My problem is with the client. The server does send the JSESSIONID with the response. But it looks like that the client's calls do not send the JSESSIONID with the request(I have tested this on TCPMon). Because of that the server creates a new session every time a request comes.
After some googling I found that I had to set BindingProvider.SESSION_MAINTAIN_PROPERTY = true in request conext in order to maintain user session in client. But sadly this also is NOT working for me.
I have tried generating the stub using AXIS and the session here is being properly maintained.
The web service has been deployed in Tomcat.
Thanks.
Related
I am currently trying Java Jersey 2.23.2 for my restful service
When both of the web client and tomcat web service runs on the same device, The session was handled perfectly.
However, when the an external client (another website) that runs on a different machine, there will always be new session introduced after an API call instead of sticking to just one session.
Is there anyway I could let the external client to call the webservice just like the local client does?
I can assume that your remote client does not care about JSESSIONID cookie. When session created, server sends HTTP header Set-Cookie with it.
Client must take it and then send it back with each subsequent requests.
All browsers do it automatically.
But as long as your client is another service it needs to care about it.
I have come across many examples of implementing a simple http server in Java. This one fits my needs: http://www.rgagnon.com/javadetails/java-have-a-simple-http-server.html
However, I can't find an example of how to generate, return, and maintain a session id from such a simple http server.
Is that even possible? Is there a way to modify the sample code referred above to incorporate this functionality?
Thanks.
HTTP does not have session support on it self once it is a stateless application protocol. So you need implement it by your self.
For example, on servlet containers like Tomcat there is a cookie called JSESSIONID that is generated and stored on the browser. The client sends back the cookie to the server on each request. Once each client has a different cookie the server can identify the client session.
When cookies are not allowed the parameter JSESSIONID is added to the URL for each request. This technique is called URL Rewriting.
There is a question, not specific for Java HTTP servers, that has implementation details for this problem.
HTTP Session Tracking
I have a Web Service (JAX-WS), a WSDL, a desktop application Client, and a Weblogic 12c server. I am trying to implement basic authentication between the Client->Web Service->Weblogic->Active Directory. I have been able to set everything up by putting the Username/Password in the header of the SOAP message when sending it from the Client to the Web Service.
Weblogic automatically pulls that header info and authenticates a user against Active Directory. Great. But the issues at hand are thse:
Should I not send credentials in the header at all, it doesn't authenticate but allows full access to anonymous users.
I need to send a proper error message and prevent anonymous usage.
Should I send invalid credentials it throws a socket read exception on the client.
I need to send back a proper error message; rather than having it bomb out on the client.
Should I send valid credentials but invalid authorization; I have setup #RolesAllowed({"SomeRole"}) on each of my Stateless EJB methods. It throws a security vilotion exception on the Web Service side of the house.
I need to somehow catch this exception and send back a proper message to the client
Is there a way to do all of this without customizing the Weblogic Domain? It feels like I need to manually take control of the Basic Authentication of Weblogic but then I feel like I am stepping the JAAS Login Module of weblogic -- which customizes the domain and I want to avoid.
Use Handlers to intercept the incoming and outgoing requests.
i have a standalone application from which using the httpclient i'm communicating with the another web application for user authentication and set the user details in session in the web application and after returning to the standalone application i have some logic to run and afterwards i'm forwarding to the web application success page (here in the success page i am unable to retrieve the session where m getting the session object value null.. ) .
So how do i preserve the session ?
Sessions are only available at the web application and the client browser!
So you need to ask the admins or find a public API how to get it, because you can't reach it from a remote machine directly.
The clients just save the id of the session within a cookie, don't store data locally, everything what you need is on the web application's scope.
I have an applet loaded by browser.
This applet makes web service calls to server.
If I sign the applet and download it via https by the server, if then I make a web service call, would it be possible to reuse the existing ssl session or will the https would have to be reestablished?
I think that the https (i.e. ssl handshake) would have to be reestablished since the initial connection was made by browser. Is this the case?
If yes, then is there a way to avoid reauthentication when the user starts using the applet? I.e. reuse the previous ssl connection, or is it impossible? BTW the web service stack is axis2.
Thanks
https and authentification are different things. Of course they are working together when you authentificate with user/password over https.
https can be used for authentification when client authentification is enabled. So the client must send a valid (signed) certificate to the server. But i supose you have a user/password over https authentifation method.
Once the browser has logged in, normally the server creates and holds a session and the browser receives a session cookie. That cookie will be send on consecutive requests after login (still encrypted by https).
If you pass the session cookie to the applet the applet can reuse the session.
Update
Impossible to explain you this in detail. You should search and read for Java Applet communication.
You can call methods of the applet from
javascript and access the web
page/browser state from the applet (Applet.getAppletContext()).
You may call the applet with a
parameter that contains the session
id.
The session cookie name may be JSESSIONID when the web server is a servlet container.
If your web server is a servlet container then you can pass the session id in diferent ways: as cookie in the request header or coded into the URL (URL rewriting).