We have configured the ELB with 2 server for the Web API. Updated the MachineKey in both the server to be same.
When the Reset Token password/Confirm password is created from server1. The Url is sent to the User Email when the Verify token call is Made the Server1 Verify the token successfuly, But if call is sent to the Server 2, Server 2 always returns Invalid Token. Do i need to make any configuration chanages other than the Machine Key.
You need to make sure that the all the request belongs to one session goes to the single backend.
In order to do this enable session stickiness on the ELB. This will make sure that request always gets routed to the same backend.
On Classic Load balancer : https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html
On Application Load Balancer : https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#sticky-sessions
Related
I have two servers, which are both stayed at the same host but different port.
One is reactjs server hosted at port 3000.
Another one is database server with API interface hosted at port 1337.
I use Axios to make api request to the database, but it only works when I make call with Public IP address (for example: axios.get("http://215.128.23.16:1337/collection/"). When I change to localhost, it shows error. (shown in attached pictures)
What I want is to make API request internally, in order to restrict the IP address of accessing the database to only localhost connection.
Here are the steps I want to achieve: Client Side make a API call from browser -> Reactjs server receive the call -> Reactjs server send API request to database server internally (then I can restrict the IP access of accessing database to localhost) -> return result
Is this possible???
I am currently running a Django site on ec2. The site sends a csv back to the client. The CSV is of varying sizes. If it is small the site works fine and client is able to download the file. However, if the file gets large, I get an ERR_EMPTY_RESPONSE. I am guessing this is because the connection is aborting without giving adequate time for the process to run fully. Is there a way to increase this time span?
Here's what my site is returning to the client.
with open('//home/ubuntu/Fantasy-Fire/website/optimizer/lineups.csv') as myfile:
response = HttpResponse(myfile, content_type='text/csv')
response['Content-Disposition'] = 'attachment; filename=lineups.csv'
return response
Is there some other argument that can allow me to ignore this error and keep generating the file even if it is taking awhile or is large?
I believe that you have any sort of backend proxy server which resets the connection to the Django backend and returns ERR_EMPTY_RESPONSE for the case. You should re-configure timeouts on your backend proxy. Usually that is nginx or apache used as a reverse proxy server.
What is Reverse Proxy Server
A reverse proxy server is an intermediate connection point positioned at a network’s edge. It receives initial HTTP connection requests, acting like the actual endpoint.
Essentially your network’s traffic cop, the reverse proxy serves as a gateway between users and your application origin server. In so doing it handles all policy management and traffic routing.
A reverse proxy operates by:
Receiving a user connection request
Completing a TCP three-way handshake, terminating the initial connection
Connecting with the origin server and forwarding the original request
More info at https://www.imperva.com/learn/performance/reverse-proxy/
One more possible case - your reverse proxy backend server doesn't have enough free space to process response from Django and aborts the request. You can also check free space on your reverse proxy balancer.
Within gunicorn, there is an argument for timeout, -t. When you run gunicorn, the default timeout is 30 seconds. Increase that to something your comfortable with like 90 or 120 seconds, whatever you think fits your application.
I'm attempting to understand how spring boot uses http sessions to manage the oauth authorization code flow.
I understand that after the user submits their credentials via the /login form spring will persist the authentication object so it can be retrieved when the browser is redirected to retrieve the authorization code.
What I dont understand is if the browser needs to sends jsession cookie to the server or http basic authentication header when invoking this flow.
For example if I wanted to initiate the flow manually via curl do I need to specify any special headers ?
It doesn't use HTTP sessions to persist it, the client ID and authorisation code (the code that's passed back to the client app after the user authenticates) is used to identify the authentication object. The authorisation code is then used to obtain the access token.
So:
The client app redirects to the auth server, passing in their client ID.
The user authenticates with their username and password on the auth server , which stores the authentication against the code and client ID and passed the authorisation code back to the calling app as a request param on the redirect URL.
The client app calls back to the auth server, authenticating with it's client ID and secret and passing in the authorisation code. This is then swapped for the access (and possible refresh) token.
If the app needs the user details, the client app calls the user details endpoint authenticating with the access token it now has.
I am building a "proxy client" extension for chrome and i have following scenario:
Users can login to the extension and get a token from API. Tokens are valid for 2 hours.
After login users can select a proxy server from a list and that proxy is set with chrome.proxy api.
I am using Squid on proxy servers. When a user connects to a proxy server and lands on onAuthRequired i return email and token as authCredentials.
Chrome uses those credentials from cache until token is not valid anymore and proxy server responses "407, Proxy Authentication Required". Now the problem i am facing here is when i login with another username on same browser and connect to same proxy server it still sends old users credentials to the server because they are still valid. My question is how can delete chromes proxy auth cache so that it lands onAuthRequired again and i can return new users Credentials.
I tried to modify the response from proxy server to "407, Proxy Authentication Required" when user makes his first request over the proxy server to force a onAuthRequired but its not working. Chrome still uses cache and still returns credentials from old user to the proxy server.
Have you tried to hook up another event handler within the webRequest API in order to manipulate the http headers before Chrome takes on authentication?
E.g. onBeforeSendHeaders or onHeadersReceived
I am working on a site that will be using HTML5 sockets to communicate with other server. At that time our users will be logged in , I can't code on other server . I am using PHP at server side. I don't know whether other server has even PHP or not. Client says PKI is a solution. So if user login on our server then I start their communication with HTML5 sockets towards other server to send and receive data. So how can other server authenticate them? I also think that I can have a userkey (like 32hash format) that is sent with HTML5 socket while communication that other server validate and then start working with that user. So client says that hacker can see data over network so I think SSL can work for it. What you guys suggest in such scenario? Please advise
More details:
There will be connection made between our users and another server using apache thrift(will be using TCP), and scenario is that user will login to our site, then we will connect them via HTML5socket to apache thrift on different domain, so in HTML5socket communication we will be forwarding userid to tell thrift server that which user is this, so it is fine. But there are two problems,
As HTML5sockets are at client side then a hacker can create his/her own socket and connect to that server in same way and use some one's id as these are just simple integers.
If we will append some thing in data then a hacker sitting on the network can get it like some hackers do this for session hijacking.
So that's why I am not sure that whether using a sort of SSL or TLS will solve the problem or some PKI or some other digital certificate. So that's why I am asking that here.
thanks
SSL cannot solve this problem. SSL is about creating a secure link between the client and server, it does absolutely nothing to protect the server from a malicious client. SSL cannot solve the problem of SQL Injection or in your case Insecure Direct Object Reference relating to the user id. Judging by this SSL suggestion you probably have never heard of TamperData, which allows you to read/intercept and modify all HTTPS traffic generated by your browser (Including components like flash and JavaScript), BURP is more advanced but does the same thing.
The right way to do this is to have a shared session store that your collection of servers can access. The client is issued a very large random number or cryptographic nonce that it uses as a verification token, which is kind of like a session id. This verification token is used to look up session state in the data store. The communal session store could be as simple as a PHP page that accepts the verification token as a parameter and tells you if its linked to a valid session.
Having 3rd parties issue a callback to verify the session is really the "right way" to do this. It is possible to do this with cryptography, although it is a misuse of cryptography because it introduces the possibility of an attack, where as a callback is absolute. The PHP server can issue the JavaScript client an HMAC token consisting of the user id, a timestamp and the message authentication code. The tricky part is that both the PHP server and any 3rd party will have to share a secret in order to verify the message authentication code. If done properly you can transmit the client can transmit the token, and 3rd parties can verify that the session hasn't expired based on the timestamp and that your servers issued the token (instead of a hacker's forgery) based on the message authentication code.