I use session's handling in redis via SncRedisBundle.
I figured out that session key's ttl is discarding on each request to it's initial value (it is 3600 in the example). How can I disable it?
framework.yaml:
session:
handler_id: snc_redis.session.handler
cookie_lifetime: 3600
snc_redis.yaml
snc_redis:
clients:
...
session:
type: predis
...
session:
client: session
I know that I can explicitly set ttl by snc_redis.session.ttl, but it has no changes to the reset of ttl.
Why is this a problem?
There can be a client (or bot) that logs in to the system, and repeatedly pings the server to indefinitely extend its session lifetime. The cookie expires is only respected by the browser, but it doesn't prevent the client from spamming the API with cURL requests. Each request resets the TTL and postpones the time until the session is actually destroyed from the cache.
Reproduce:
Login.
Check session key's ttl. It should be 3600 at the beginning.
Refresh page.
Check session key's ttl. It should be lower than 3600, but it is reset to 3600 again.
Related
I'm trying to limit Fastapi to process 1 request at a time. And while that request is being executed, other requests gets response that the Server is busy.
I cannot understand your requirement but you can either
Use a library such as https://github.com/long2ice/fastapi-limiter or
https://github.com/laurentS/slowapi to handle limits
Write a middleware that sets a flag in Redis or some other in-memory database, whenever a request comes, check if the flag is True. If True reject the request and if False set it to True and process the request. Set the Flag to False when the Response is sent by the server.
I'm trying to implement a solution to identify if there was an idle time of X minutes between two requests.
For this, I'm planning to use the following approach.
Initially, set a cookie from the application side. The expiry time of this cookie is set to X minutes.
Whenever there is a request, in nginx, I will check if the cookie expiry time is passed or the cookie is available.
If the cookie is available, and not expired, I will update the expiry time again with X minutes. Otherwise, delete the cookie.
On the server-side, I can check the availability of the cookie and if available, I can conclude the previous request was within X minutes.
To implement this solution, I will need some code snippets as below.
if cookie-exists and cookie.expirytime > currentTime
Set-Cookie: MY_COOKIE=SOMEVAL; Max-Age=X*60; Secure; HttpOnly
else
Drop-Cookie MY_COOKIE
endif
How can I implement this condition check and cookie modification in nginx? Is it possible to do without lua?
I don't want to implement this logic on the application side because - there are multiple applications served through nginx and I want to keep the logic common to all. If the user is hitting any of the applications, the cookie should be updated.
Browsers do not send expired cookies, so Nginx will never receive it. You could potentially set 2 cookies: one that expires, and another that identifies repeat visitors.
Since session and cookies are both used to store temporary data, what is the difference between them?
As for may knowledge:
If you set the variable to "cookies", then your users will not have to log in each time they enter your community.
The cookie will stay in place within the user’s browser until it is deleted by the user.
But Sessions are popularly used, as the there is a chance of your cookies getting blocked if the user browser security setting is set high.
If you set the variable to "sessions", then user activity will be tracked using browser sessions, and your users will have to log in each time they re-open their browser. Additionally, if you are using the "sessions" variable, you need to secure the "sessions" directory, either by placing it above the web root or by requesting that your web host make it a non-browsable directory.
The Key difference would be cookies are stored in your hard disk whereas a session aren't stored in your hard disk. Sessions are basically like tokens, which are generated at authentication. A session is available as long as the browser is opened.
hope following links will further clarifying your doubts
http://wiki.answers.com/Q/What_is_the_difference_between_session_and_cookies
http://www.allinterview.com/showanswers/74177.html
Cookies store a user's data on their computer.
Session implementations store a user's temporary data on a server (or multiple servers, depending on the configuration).
In each HTTP response, the server has the opportunity to add a header Set-Cookie: {cookie-name}={cookie-data}; {cookie-options}.
The browser will, in every subsequent HTTP request (or as specified by the options), add a header Cookie: {cookie-name}={cookie-data}.
Request #1:
POST /auth/login HTTP/1.1
Host: www.example.com
username=Justice&password=pass1234
Response #1:
HTTP/1.1 307 Temporary Redirect
Set-Cookie: user_id=928
Location: http://www.example.com/dashboard
Request #2:
GET /dashboard HTTP/1.1
Host: www.example.com
Cookie: user_id=928
Response #2:
HTTP/1.1 200 OK
Content-Type: text/html
<html>
<head>...</head>
<body>...</body>
</html>
All future requests will also include the Cookie header.
Cookies are stored on the client as either small text files on the files system (persistent cookies) or in the browsers memory (non-persistent cookies) and passed to the server and returned to the client with each request and response. Persistent cookies will still be available between browser sessions as long as the expiry date has not passed. Non-persistent cookies will be lost once the browser is closed.
Session is stored on the server in memory. Cookies are very often used as a way of preserving the reference to the users session between requests however this can also be done with querystring parameters if cookies are disabled on a clients browser.
A cookie is client side a session is server side
Sessions are stored server side. You can have inproc sessions, which will be stored in memory, or you can store the sessions in an SQL database. You can read more here.
Cookies are stored on the client's computer. This means that it's not recommended to store important details in a cookie, because clients could easily manipulate them.
Cookies are a small text file stored on the client that can hold domain specific information,
a session is held server side in either memory, a database or a seperate server and keyed via a session key, they are meant only to persist for a 'session' where as a cookie can persist for a length of time or indefinately therefore being usable in multiple sessions.
They are not the same thing. A Session is a concept whereby the state of a single user's browsing session is stored.
Cookies are a good means of implementing this concept, thus the widespread practice of "Session cookies".
The main difference between data stored in session and cookies is that data stored in session is stored on the server side (user can't operate on such data), while cookies are stored on a client side. They might be manipulated somehow by user. If you have a really sensitive data - then store it in session. But all other data you can store in cookies not to overload the server.
Since HTTP is a stateless protocol, when a client makes a number of requests to the server, how does the server uniquely identify a particular client's requests over a period of time say t1, t2, t3..
I browsed the web and came across terms like session id, URL rewriting and cookies. But it would be great if someone explains it in a better way. Specifically which part of the HTTP request and response would be used for session tracking?
As you mentioned, common ways to implement HTTP session tracking include URL rewriting and cookies. Session tracking basically requires that a session ID is maintained across multiple requests to the server. This means that each time a given client makes a request to the server, it passes the same session ID. The server can use this ID to lookup the session information it maintains.
When using cookies, the server asks the client to store a cookie by setting the Set-Cookie HTTP response header. This cookie contains the unique session ID assigned to that client - in this example the string 'ABAD1D':
Set-Cookie: JSESSIONID=ABAD1D;path=/
The cookie is then sent back to the server by the client using the Cookie HTTP request header on each request and thus the server is informed on each request the session ID currently assigned to the client.
Cookie: JSESSIONID=ABAD1D
When using URL rewriting, this same session ID is instead sent somewhere in the URL. Again, the server extracts the session ID from the URL so that it can lookup the session for a particular client:
http://my.app.com/index.jsp;JSESSIONID=ABAD1D
However, the server must also make sure that any URLs in the web pages sent back to the client are also rewritten to contain that particular clients session ID. As the session ID is encoded in the URLs, this method of session tracking is transparent to the browser. Often a server will resort to URL rewriting if it finds it is unable to set a session cookie on the client - implying that the client does not support/allow cookies.
Note that sessions can expire. This means that if the server does not 'see' a given session ID for a period of time, it may remove the session data to preserve resources.
Specifically which part of the HTTP
request and response would be used for
session tracking?
In the HTTP response, the server can set a cookie. It does so with the Set-Cookie header. For example:
Set-Cookie: session=12345; path=/
The client then returns the value of all cookies that match the properties that were set along with the cookie, which can include path (as above) and domain, and that haven't expired yet.
The cookie is sent back to the server as part of the HTTP headers. For example:
Cookie: session=12345
None of the original property information is sent back with the cookie.
A unique cookie allows the server to associate a unique key with a particular browser instance. The server can then use that key as an index into a hash table or a database table that holds unique per-user state information.
Session tracking is a server side thing.
A web server issues some session identifier that is returned to the browser. Browser submits this session identifier along with each request.
This is probably done using cookies transparently for the user.
the session handling is in most case handled by sending a cookie to the client. that cookie would be sent back to the server on every request from that particular client.
The session id will be associated with some resources on server side (file,ram space) so the server by reading the session id in the cookie can find this resource and then know which client it was.
Find enough details here
HTTP Sessions are the recommended approach. A session identifies the requests that originate from the same browser during the period of conversation. All the servlets can share the same session. The JSESSIONID is generated by the server and can be passed to client through cookies, URL re-writing (if cookies are turned off) or built-in SSL mechanism. Care should be taken to minimize size of objects stored in session and objects stored in session should be serializable. In a Java servlet the session can be obtained as follows:
HttpSession session = request.getSession(); //returns current session or a new session
Sessions can be timed out (configured in web.xml) or manually invalidated.
HTTP Session allows web servers to maintain user identity and store user specific data during multiple request/response between client and we application
This web page http://www.w3schools.com/ASP/prop_sessionid.asp states that a session ID is generated on the ServerSide.
If this is the case, then how does a server know it's still the same client on the 2nd request response cycle?
Surely the SessionId would be generated on the ClientSide so that the client would be sure of passing the same value to the server?
The SessionID is generated Server Side, but is stored on the Client within a Cookie. Then everytime the client makes a request to the server the SessionID is used to authenticate the existing session for the client.
The session ID is normally generated on the server. It's then sent to the client, either as a cookie in the HTTP headers, or by including it in the HTML, i.e. the links become href=my.html?sessionid=1234.
The client's next request will then contain the session Id, either in the cookie or the GET part of the request.
The server will generate a session id if none exists. But once it has been generated, the client can pass that id back to the server. If the client modifies that id, you would likely get an error from the server, and a new id generated.
The ID is generated on the server. The client then stores this in a session cookie that the server picks up on subsequent request.
If the server is running in cookie-less mode, then the session key becomes part of the URL and the server parses it from there.
ADDED: ...and if the server is expecting to use a session cookie but the client has cookies disabled, then from the perspective of the server, all requests are new sessions as it cannot tell that this is the same user.