I have the following configuration:
backend webservers_backend
cookie SERVERID insert indirect nocache
stick-table type string len 40 size 20k
stick store-response set-cookie(SERVERID) table webservers_backend
stick on url_param(SERVERID) table webservers_backend
server memtom1 ip1 check inter 5000 cookie memtom1
server memtom2 ip2 check inter 5000 cookie memtom2
however it does not work when using url parameters only when i use cookies, however, flash does not support cookies.The call from flash(getConfig?val1=xcv93ec9&SERVERID=memtom2;%20path=/) i also try(getConfig?val1=xcv93ec9&SERVERID=memtom2)
HAProxy can't store in a stick table headers it has
itself setup.
So the line
stick store-response set-cookie(SERVERID) table webservers_backend
will work only if the server set-up the cookie.
Related
I am passing the application_name to my postgres server in the uri like
postgres://username:password#host:port/database?application_name=name
My question is how I can force every incoming connection request to supply this parameter? For logging reasons I don't want to allow connections without this name.
Is that possible?
When I look the stats page ogf my haproxy, I wonder if the term "session" represents the number of different users who are connected to my haproxy.
Session shows number of sessions. Two sessions opened from the same ip address will be shown as two sessions. I don't know a better solution for you than to use socat and "show sess" command. https://cbonte.github.io/haproxy-dconv/1.7/management.html#9.3-show%20sess
then group and count sessions with unique src address.
I am relatively new to using haproxy, and I am trying to figure out if it is possible to use a consistent hashing algorithm to hash a cookie value in to a separate header. This seems very similar to how you would use a consistent hash-type (http://cbonte.github.io/haproxy-dconv/1.8/configuration.html#4-hash-type) for load balancing, but I don't see how you could put the output of that hashing in to a header for backend servers to see.
My use case is that I have a 'uuid' cookie which I want to use to assign users to a pool 1-100 to use in A/B (/C/D... etc) tests. Today we do this in a nodejs app, but we are adding new backends and we want to avoid implementing the same hashing in multiple languages.
I'm currently using haproxy 1.8. I appreciate any suggestions!
use this
http-request set-header header_name %[req.cook(your_cookie),sdbm,mod(100)]
Our current implementation of the REST API uses apiKey inside queryString for all type of request(PUT, POST, GET). I feel it's wrong but can't explain why(maybe the apiKey can be cashed somewhere between server and client). Something like:
POST /objects?apiKey=supersecret {name: 'some'}
So, is it a security problem? Please describe both HTTP and HTTPS connection case
HTTP
Your supersecret values can be seen and intercepted by thirdparties whenever you send it from the client to the server or vice versa irrespective of whether you use PUT,POST, etc. This is even true when you use cookies for storing those values instead of query string.
HTTPS:
When the data is in transit between your client and server it cannot be intercepted since its protected by https, even if it is in query string. But most people consider sending data in query string as bad, since many system logs the query strings. For eg most servers are configured to print the access logs with the path & query parameters. Also if its from a browser it can be stored in your browser history.
I need to know the maximum length of
JSON Web Token (JWT)
In specs there are no information about it. Could be that, there are no limitations in length ?
I've also been trying to find this.
I'd say - try and ensure it's below 7kb.
Whilst JWT defines no upper limit in the spec (http://www.rfc-editor.org/rfc/rfc7519.txt) we do have some operational limits.
As a JWT is included in a HTTP header, we've an upper limit (SO: Maximum on http header values) of 8K on the majority of current servers.
As this includes all Request headers < 8kb, with 7kb giving a reasonable amount of room for other headers. The biggest risk to that limit would be cookies (sent in headers and can get large).
As it's encrypted and base64ed there's at least 33% wastage of the original json string, so do check the length of the final encrypted token.
One final point - proxies and other network appliances may apply an abitrary limit along the way...
As you said, there is no maximum length defined in the RFC7519 (https://www.rfc-editor.org/rfc/rfc7519) or other RFCs related to JWS or JWE.
If you use the JSON Serialized format or JSON Flattened Serialized format, there is no limitation and there is no reason to define a limitation.
But if you use the JSON Compact Serialized format (most common format), you have to keep in mind that it should be as short as possible because it is mainly used in a web context. A 4kb JWT is something that you should avoid.
Take care to store only useful claims and header informations.
When using heroku the header will be limited at 8k. Depending of how much data are you using on jwt2 it will be reach. The request, when oversize, will not touch your node instance, heroku router will drop it before your API layer..
When processing an incoming request, a router sets up an 8KB receive
buffer and begins reading the HTTP request line and request headers.
Each of these can be at most 8KB in length, but together can be more
than 8KB in total. Requests containing a request line or header line
longer than 8KB will be dropped by the router without being
dispatched.
See: Heroku Limits