I found sth like this:
"stateful – keep track of the previously stored information which is used for current transaction.
stateless – every transaction is performed as if it were being done for the very first time. There is no previously stored information used for the current transaction.
In a purely stateless environment you wouldn’t need this session id. Each request would contain all the information the server would need to process. But many applications need to maintain state to keep track of whether or not a session is authenticated to view certain content or to keep track of what a user is doing. You wouldn’t want to send user credentials over the wire for each request."
I'm quite confuse. So if stateless session with cookie maintain the state so it's mean that:
stateless session with cookie= session stateful?
Another think. I found information that session stateless is client side session and stateful is server side session. How we can discuss about client side session if stateless session does not maintain session?
In a purely stateless environment you really don't need sessions or cookies.
Both sessions and cookies are used to maintain state. The only question is where. Cookies maintain the state on the client while sessions maintain state on the server.
From Wikipedia: Representational state transfer
The session state can be transferred by the server to another service such as a database to maintain a persistent state for a period and allow authentication.
So typically in a stateless design, yes there is no state between client requests.
Every client request will have sufficient info to perform the requested action.
However, you still need authentication and/or authorization so who the client is identified from request headers (typically).
Related
I am using Spring Session JDBC to persist sessions in my application. I am aware that this implementation does not support HTTP event publishing. However, I have a requirement to log session creation, expiration, and destruction. If I get some sort of notification that the session was destroyed, I already know how to determine if it was a logout or timeout.
I realize that the obvious answer is "don't use JDBC". However, I do not have the option to stand up Redis or Hazelcast due to strong port-management policies of my organization. If I want to open the Redis or Hazelcast ports, management has to get involved.
I'm asking if anyone has figured out how to "fake it", and determine if a sesson is created or destroyed in the absence of an HttpSessionEventPublisher. I have one idea which is the equivalent of a very large hammer approach, so I'm wondering if anyone else has done this in the past.
Currently using Spring Session Redis in a Spring Boot 2.5 web application.
The application correctly receives web session expiration notifications from Redis, but AFAIK only if the application is up and running at that time. It seems that if the backend is stopped at that time (crash, planned maintenance, ...), the notifications are not "kept" or "delayed" until the backend is up again, they are simply lost.
In https://redis.io/topics/notifications from "if your Pub/Sub client disconnects, and reconnects later, all the events delivered during the time the client was disconnected are lost" I understand that this is the standard Redis behavior.
Is this indeed the current Spring Session Redis behavior ?
Are there recommended solutions to "delay" the notifications ?
As you mentioned, this is the standard behavior of Redis Keyspace notifications.
If a key expires while the application is down, the expiry event cannot be processed, there is no way to delay the notification.
In the context of session expiration in Spring Session Data Redis, this means that the SessionExpiredEvent/SessionDeletedEvent will not fire if the application is down (crashed etc) when the Redis Keyspace notification is sent.
This will cause problems if you have a task dependent on these events.
It also means that resources may not get cleaned up properly.
However, from a security standpoint, the session will still expire correctly and the user will not be able to continue using the expired session.
If an application is performing a critical task on expiry, a different data store may be a better fit, given the "fire and forget" nature of Redis Pub/Sub.
Alternatively, having multiple nodes will make it unlikely that they will all be down at the time of receiving a notification.
I am writing a web application in Rust/actix-web and I am looking for a way to store data related to sessions on the server side. The session data does not contain any user data or such. The web app is a game/simulation of a specific mathematical problem on big graphs. Hence, the session data contains information attached to the nodes of the graph.
I found the actix_session API which makes it possible to store session data and send it with a cookie but I don't want the whole session data to be sent because it might be very large and the client should only receive junks of it when required.
Is there a way to maintain (cookie) sessions without sending the session data directly with the cookie or are there even other solutions than cookie sessions?
I'm relatively new to Spring, and trying to queue up a set of web reqeusts on the server (in order to warm memcached). It's unclear to me how I can transfer on the current request's credentials to be used in the future web request I'm putting in the queue. I've seen a handful of scheduling solutions (TaskExecutor, ApplicationEventMultitasker, etc) but was unclear if/how they handle credentials, as that seems to be the most complicated portion of this task.
It's not possible directly. Security credentials are stored in ThreadLocal which means once the request is forwarded to another thread, credentials are lost. All you can do (which might actually be beneficial to your design) is to pass credentials directly, by wrapping them inside Callable/Runnable or whatever mechanism you use.
Is there any way i can access the object of one client session from another client session?
Unless you have isolated your Entities to the client Session (ClassDescriptor.setIsIsolated) then the ClientSession does not actually hold any entity instances. So unless you have caching disabled all queries against a ClientSession will return the same entity instances.
If you have isolated Entities or are actually using a UnitOfWork then you will have to get the value from the holding UnitOfWork/IsolatedClientSession. It is not advisable to access a UnitOfWork or ClientSession concurrently with multiple threads.
I'm not sure to get what you're trying to achieve but, according to Server and Client Sessions from the TopLink Developer Guide, you're not supposed to share client session accross multiple threads:
Although client sessions are thread-safe, do not use them to write across multiple threads. Multithread write operations from the same client session can result in errors and a loss of data. For more information, see "Concurrency".
Could you clarify why you would need this?