i am developing a server application of building rest web services in java using spring-hibernate,where this service will be used by other clients.i have followed this link http://www.beingjavaguys.com/2014/08/spring-restful-web-services.html.
my question here is
1>should i maintain session in server application?if yes how?
2>should i do any validation in server side?
3>To validate user while login should i use spring security for that or just comparing username and password in database is enough?
4>when user doesnot interact with server for particular time there should be session timeout ,should this be implemented in sserver application or client side?
i am very new to java and web service,any suggestions,links and guidence are appreciated.
1>should i maintain session in server application?if yes how?
Rest web services do not depend on client session since they are stateless, so there is no need to think about session management.
2>should i do any validation in server side?
What kind of validation?
3>To validate user while login should i use spring security for that or just comparing username and password in database is enough?
You can use both, but I think a token based authentication (Based on spring security) will be the best way.
4>when user does not interact with server for particular time there should be session timeout ,should this be implemented in server application or client side?
Since server does not keep track of user session, timeout should be implemented on client side.
You can check the following project if you want its a excellent starting point.
https://github.com/dhavaln/spring-rest-boilerplate
1>should i maintain session in server application?if yes how?
Web-services are stateless means server does not store any state about the client session on the server side.You should manage the session on the client side, other wise you will end-up handling an heavy load of sessions on the server side and I am sure you don't want to do that.
2>should i do any validation in server side?
If by validation you mean data integrity, I think you will have to do it for the favor of data integrity and your application well being.
3>To validate user while login should i use spring security for that
or just comparing username and password in database is enough?
You can do both, using spring security is a good choice , and you will have to configure or build your own AuthentificationManager which will compare credentials withe those stored in the database
4>when user doesnot interact with server for particular time there
should be session timeout ,should this be implemented in sserver
application or client side?
You can set a session timeout , and this should be implemented on the client-side.
Related
I was wondering that session management in cloud environments are available in many options for Microsoft azure/ Amazon Web Services / any private cloud. What I was looking that which is the best session management technique which will fit in all the cloud environments.
I have gone through many site but could not decide which is the most suitable in all cases. I read somewhere that Sticky sessions are also one of the option for session management. So looking for an answer which states that is Sticky sessions are different from cookie based session management?
If yes then how to use it?
Thanks
Ravi
Sticky session are likely to stay on same server when the first request comes and provided from same server for each request. Where as cookie based session are nothing but keeping the data on client machine in browser. can be served from any server which is available.
Yes Sticky Sessions are different than cookie based sessions.
As sticky sessions are nothing but handled by load balancers which handles to get sessions in request from client and passes it to the same server where the first request came to that server. E.g. While loading an website request goes to server A, then sessions get stored on server A, while next request comes from user the request sent to the same server i.e. Server A, irrespective of how many servers present in the farm.
Whereas cookie based sessions are stored on client machine, and it gets added with each new request. So it can be read and supported on any server in farm irrespective which server generated and stored session while first login.
Why sharing session to implement SSO is not good? I'm learning SSO system.
Thinking about this scenes:
Assume that all http requests to business services is required Login, the business services need verify the requests is login or not by asking SSO service in CAS or SAML. If there are 10 business services, and each service's request is 1k req/s, so the SSO service's request is 10k req/s. It's hard to image the SSO service can hold on.
SO, may be there is a cache mechanism in the business services to verify login token. But when user logout, the SSO service need remove the verify info, and the business services need remove the cache verify info also. I think that's too complicated. The SSO service need tell the business services some people was logout. So why don't all service sharing the login token verify info? Let SSO service write, and other business read. It remind me the sharing the session to implement SSO. And I thought if I can sharing the login token verify info by redis distributed cluster. But I have hear sharing session is not good? So why?
Whether the SSO server can handle that many requests depends on your deployment of it. There are very large deployments of CAS that handle hundreds of thousands of requests. It varies.
In general, the SSO session is entirely separate from your application session. Once you have logged onto the application via SSO, you have established a session for that application that will last for as long as you configure it to last. When it expires, your application may decide to authenticate against your SSO server again. If the SSO server has still an SSO session, it will simply re-issue the appropriate data and your app will recreate the session. If not, it will challenge the user for credentials, whatever they may, and redo the same.
Session concerns of the application are entirely yours and application's concerns. The SSO server should never get involved. If your application has a requirement to share sessions because it's clustered, then you should share sessions. Nobody said it's a bad idea. However, you generally want to make sure your application is as stateless as possible since that will make clustered deployments easier.
When you log out from your application, your app session is gone, but the SSO session may still exist. As a result, you will get right back into the app because there is no need to provide credentials. If you wish, you could log out of the app AND your SSO server.
If you have all other applications logged in via SSO, and you wish to log out of all by logging out of one, this is called SLO. Your SSO server will need to reach out to every app that it has created a ticket for and contact them to logout. Or, you could destroy the shared sessions for all apps assuming they are all part of the same suite.
How can i use single session for both clojure and clojurescript.
For my login web application Server side i am using clojure and client side clojurescript.
And i need a session which is accessible from both client and server.
Is that possible?
The example sente project has a session which is accessible from both client and server. You will probably need to spend some time with it and mould it to your needs. But the example itself shows logging in and then a :uid inside :session, which is accessible from both the server and the client.
I have a application that use Jpa Hibernate,Spring Data, Spring security, but I want more control over password rules and users, for example, password expiration time, session time, inactive session time, etc.
Spring security can do all these tasks automated?
Other possibility is to use LDAP, to control password policy, but I already have users defined in my application and I can't see how LDAP server can read my users to apply the polices, or the users have to be in the LDAP server to authenticate in my application?
I installed apacheds server to test.
I need to know if I'm using the right approach to solve this problem.
If you use the LDAP password policy it will apply to existing users next time they change their passwords, and you can force them to do that.
Session inactive/expiry time has nothing to do with password policies as implemented in LDAP.
For a web application I could figure no session cookies stored . There was a string as
SSLJSESSION=0000SESSIONMANAGEMENTAFFINI:-1
From my understanding , this cannot be used to handle sessions , Still the application is handling the sessions properly .
Can anyone please tell me how session handling is done with the above technique ?
After a bit of browsing through WebSphere’s documentation, I found out that WebSphere (actually IBM HTTP Server as well as SUN One Web Server) support a feature called SSL ID Session Tracking. Basically, what this does is bind web application sessions to SSL sessions. This further does not require the web application to do almost any session handling since the server performs this on behalf of the application.