In Nginx, there are three methods regarding session persistence: sticky cookie, sticky route and cookie learn.
Below is a brief explanation about how cookie learn method works, which extracted from Nginx Load Balance:
The cookie learn method. With this method, NGINX Plus first finds
session identifiers by inspecting requests and responses. Then NGINX
Plus “learns” which upstream server corresponds to which session
identifier. Generally, these identifiers are passed in a HTTP cookie.
If a request contains a session identifier already “learned”, NGINX
Plus will forward the request to the corresponding server.
My question is that what if two upstream server generated the same session_id, then how does the prxoy server know which upstream server it should send the request?
Related
So I am trying to automate a JMeter script that creates Keycloak users and then signs them in.
First It GETs the login page and stores the code, here is an example request:
GET http://Keycloak.com:8001//auth/realms/REALM/protocol/openid-connect/auth?response_type=code&client_id=CLIENT&scope=openid%20profile%20email&nonce=N5b3a2da23c04a&response_mode=form_post&resource=RESOURCE&state=2SJwtlVZrswlGkw&redirect_uri=REDIRECTURI
However, when I then GET the registration page, the code changes and the tab_id also changes. How can I keep keycloak from generating a new code token with every HTTP request in a thread?
In addition, why is each HTTP request with JMeter acting like a new session instead of the next request in a series?
EDIT:
I am using Regular Expression Extractors in order to track the code and execution variables, in addition to using a HTTP Cookie Manager and HTTP Cache Manager for the thread.
Looking at my POST request, both variables are the same as those from the previous HTTP request, and all of my cookies are being maintained, yet every time I try this automated login, I get a 400 error and the keycloak event log displays an invalid_code error.
Edit:
As requested here is a screenshot of all my sign in requests
Most probably your Regular Expression Extractor is not nested in the HTTP Request you are trying to extract data from.
If its scope is too wide, it applies to all HTTP Requests, so first time it succeeds extracting, but then for the next request that does not contain the token, the extractor runs and overwrites the old value by an empty one.
See scoping rules in JMeter:
https://jmeter.apache.org/usermanual/test_plan.html#scoping_rules
You need to maintain the corelation between hits. Please go through below blog
https://www.blazemeter.com/blog/how-to-handle-correlation-in-jmeter
According to keycloak you must use https if you are using keycloak.com
Keycloak can run out of the box without SSL so long as you stick to private IP addresses like localhost, 127.0.0.1, 10.0.x.x, 192.168.x.x, and 172..16.x.x. If you don’t have SSL/HTTPS configured on the server or you try to access Keycloak over HTTP from a non-private IP adress you will get an error.
So you have 3 options: use private IP address, use a reverse proxy or load balancer to handle HTTPS or enable HTTPS for the Keycloak server.
I am sending a websocket connection to the API server on a different host:
new WebSocket("ws://localhost:3000")
Whereas my front end is hosted on localhost:8080.
Inside my API's websocket connection handler I'm able to set a key on the session (with Sinatra's enable :sessions) but every time I refresh the html page, the data is lost.
Is there some requirement for sessions that the front end share the same host as the server? Or is there some way I can get around this? By the way, the front end is running on a Webpack server (Node).
I also tried adding a cross_origin allowance for the API's root route http://localhost:3000 and then doing this in the client (this example in coffeescript):
$.get "http://localhost:3000", ->
new Websocket("ws://localhost:3000")
My thinking was that maybe the session needed to be "initialized" over http:// instead of ws:// but it didn't work either. The session didn't work for the $.get "http://localhost:3000" request either. Refreshing the page shows that the session clears each time.
As we've discussed in comments, you probably have a problem with 3rd party session cookies in the browser.
Here's a scheme that you could use to work around it.
Client makes webSocket connection for the first time.
Server sends a webSocket message back with sessionID in it.
Client stores sessionID in a first party cookie (e.g. a cookie in the host web page).
User hits refresh.
Web page checks to see if it has a webSocket session cookie in the cookies for the host page. If so, it constructs a URL for the webSocket connection that includes that session ID `new Websocket("ws://localhost:3000?session=xyslkfas")
When server accepts webSocket connection, it checks the query parameters to see if there is already a session being specified. If so and that session is still valid, it hooks up that connection to that session. If not, it creates a new session and goes back to step 2.
Today I faced the term "cookiejar" (package net/http/cookiejar). I tried to gather some information regarding it, but got nothing intelligible came out. I know that cookie is key/value pairs that server sends to a client, eg: Set-Cookie: foo=10, browser stores it locally and then each subsequent request browser will send these cookies back to the server, eg: Cookie: foo=10.
Ok, but what about cookiejar? What is it and how does it look like?
As you described in your question, cookies are managed by browsers (HTTP clients) and they allow to store information on the clients' computers which are sent automatically by the browser on subsequent requests.
If your application acts as a client (you connect to remote HTTP servers using the net/http package), then there is no browser which would handle / manage the cookies. By this I mean storing/remembering cookies that arrive as Set-Cookie: response headers, and attaching them to subsequent outgoing requests being made to the same host/domain. Also cookies have expiration date which you would also have to check before deciding to include them in outgoing requests.
The http.Client type however allows you to set a value of type http.CookieJar, and if you do so, you will have automatic cookie management which otherwise would not exist or you would have to do it yourself. This enables you to do multiple requests with the net/http package that the server will see as part of the same session just as if they were made by a real browser, as often HTTP sessions (the session ids) are maintained using cookies.
The package net/http/cookiejar is a CookieJar implementation which you can use out of the box. Note that this implementation is in-memory only which means if you restart your application, the cookies will be lost.
So basically an HTTP cookie is a small piece of data sent from a website and stored in a user's web browser while the user is browsing that website.
Cookiejar is a Go interface of a simple cookie manager (to manage cookies from HTTP request and response headers) and an implementation of that interface.
In general it is a datastore where an application (browser or not) puts the cookies it uses during requests and responses. So it is really a jar for cookies.
Im learning Session Management and i have two questions for which i could not find answers on the web.
Once the user is authenticated, the Server creates the Session ID and sends it the client (user) in the form of a cookie. This cookie is then subsequently used in request the client sends to the server to identify himself among other users.
Now in HTTPS session, the requests sent between the client and server is secured, as requests from client are encrypted using the Public key and it can only be encrypted using the Private key which the server only has.
But initially when the server sends the cookie information to the client, it could be intercepted by anyone as even if this cookie which contais the session ID is encrypted using the Private key, it could be decrypted by anyone having the Public key. So, my question is :
1) how does the server make sure that the session ID created by the server is securely sent to the client.
2) I learnt the client sends the cookie for each request it makes to the server. In GET request, how does the client send the cookie information as GET does not include the body .
When HTTPS is used a secure connection is established before any HTTP requests are actually sent.
Transport Layer Security (TLS) and its predecessor SSL are not built on top of HTTP, but the other way around. They are one or two layers below HTTP in the OSI model. HTTP doesn't care whether the connection that it uses is encrypted or not. The browser just requests resources and sends header information such as cookies along with it.
You can check this yourself. Run a capture software like wireshark and look how the connection is established for a website using HTTP and HTTPS.
I'm trying to do a simple load-test in a website which requires you to log in first.
I read the jmeter documentation about the cookie manager and looks like as long as I make all my requests within the same thread group where the cookie manager is the sessionID is shared among the http requests but is not my case.
The simple structure I have is:
Thread Group
HTTP Cookie Manager
HTTP Requests Defaults
Simple Controller
http request // POST method to authenticate in the site (this works fine, I get a session id)
http request // GET method (this one should use the same session id from the previous http requests but I get a new one instead)
I did this same web page flow in firefox using firebug to see the requests/responses and the session id is the same, the server doesn't send a new one so looks like the cookie manager is not keeping the same session id and using it for all the requests.
Can someone point me in the right direction? What I am doing wrong?
Check the get request sends the same jsessionid cookie in the request as the one returned in previous response.
If it's the case then check your login was fine, as it is probably root cause of issue