If users authenticate with Auth0, get a token, and then send that token on every request, what would be the point of ELB sticky sessions? I'm assuming sticky sessions are not necessary with token-based authentication and that the same user could safely hit difference EC2 instances on each request without any strange behavior. Is that correct?
Generally speaking, yes. If you aren't saving session state on the application server itself then you can safely hit different servers for each request and not miss a beat.
However, one thing to consider is what happens during application updates?
Let's say you have a website. Then you update that website with a new menu button which directs users to a new page. If you aren't using blue/green deployments, then at some point in the update process you will have two versions of your app running. So imagine the user goes to your website home page which gets directed to version 2.0. The user clicks the newly added button. This request is fielded by a version 1.0 server and now you've got a 404 error because it has no idea about the new page.
You can use sticky sessions not strictly for session state, but for application version consistency during updates.
Related
I have an Authentication microservice in Pivotal cloud foundry which is built on Spring SAML2. It is integrated with PingFederate IDP. Whenever this service is invoked from a web application, a JSESSIONID is created. In order for this service to work properly, sticky session needs to be enabled. The http request for auth and the response has to be handled by the same service instance in PCF. However, it is not happening. Request is going out from one instance and response coming back to another instance. Since the response doesn't find the SAML message in current session, the authentication fails. Below is the flow -
Browser-->GoRouter for UI-->Angular UI Service and Nginx Reverse proxy-->GoRouter for API-->Auth Service-->PingFed
PCF allows to have sticky sessions based on JSESSIONID. However, when the web app tries to access Auth service through Nginx reverse proxy, there are 2 VCAP_ID's created for a single JSESSIONID. Due to this, the response from PingFed is not able to reach the same auth service instance from the request went out. So, i would like to know why PCF is creating 2 __VCAP_ID's for a JSESSIONID, when the request comes through reverse proxy?
I tried different storage like redis. But, since the Spring sAML2 works on httpstorage, i was not successful. It will be like hacking the Spring Saml2 which i don't want to do.
I tried to check which app the VCAP_ID's belong to by restage the applications. I got to know that one VCAP_ID was for reverse proxy instance and the other one was for the auth service. So, the VCAP_ID for the reverse proxy is causing the issue and am not sure how to eliminate that.
Expected: PCF should create ONE VCAP_ID for a JSESSIONID per instance.
Actual: PCF creating TWO VCAP_ID's for a JSESSIONID per instance
I am trying to implement simple slack bot. So I have configured hubot which will take inputs from slack and passing it to my webapp (django app) and it will take whatever the response from django-app and will reply to slack.
In this process I am trying to store session in django using request.session but that is not reflected in slack. If I am accessing the django-url in browser it is able to store sessions and getting proper response with session.
So does the problem lie with slack or my approach and is there a way to store sessions in hubot when requesting to django-app ??
I can not speak to the specific technologies you use (hubot, django), but I am using server sessions with my Slack apps all the time and can give you a general answer on how it works. Note that my Slack apps are build with PHP, but I think its safe to assume that the principles are the same.
Slack does not support sessions
In general Slack does not support sessions or context. Instead everything is request based. So if you want to have sessions to keep a functional context between requests you need to organize that by yourself in your Slack app.
Challenge for using server sessions with server requests
One challenge is that most server sessions are designed to work with a client that uses a browser. e.g. a PHP server session will store a cookie in the browser, so the server knows, which requests belong to the same session. This does obviously not work with Slack, since all Slack requests are coming from a server and and there is no browser involved.
Approach for using server sessions with Slack
But you can use severs session with Slack with these two tricks:
Manually set the session ID
Usually the ID of a session is chosen automatically by the server, but you can also set it manually. This allows you to tell the server to continue an existing session that was started with a previous request.
Include session ID in Slack control
The functional session of a user is tied together by the Slack controls he uses. (e.g. an interactive button). Its possible to include custom data in those controls (see this answer for details) and that allows you to include the current session ID in it.
Full approach
You include the ID of your current session in the Slack controls, that you create with your app (e.g. an interactive button). Once the user clicks a button Slack will send a request to your app, which will include the session ID. That allows your app to continue an already started server session.
This is the first time i am doing the deployment from my side and am new to AWS. I have a project deployed on Amazon AWS server for testing purpose. I have set the domain name as: https://domain.biz
I have a login page here where once the user logs in successfully i am setting the userId in the session and navigating the user to dashboard.
In the dashboard i have added a function to check whether session set with value of userId. If the session is not set then i am navigating user back to login page. This is to block the unauthorized access to site.
I am facing problem here. when i was working with the server before adding ssl it is working fine.after https://domain.biz session is working one page.and http://domain.biz works fine. When i have added domain to https then the session is not working. What is the problem here with AWS? Am i missing anything.
Check this : Session lost when switching from HTTP to HTTPS in PHP
Since codeignitor is in php, I suppose this thread could solve your issue.
I'm developing a Facebook connected website using the PHP SDK and I am looking for guidance on best practices for scaling.
I have two pages
http://www.example.com/foo.php -> User reads about the web app here and Authorizes the Facebook application
The user is then has the option to go to another page:
http://www.example.com/bar.php -> Custom page generated for the user based on data queried using FQL
I am looking to distribute this application across a series of servers on PHPFog and they are sitting behind a load balancer. This means that the user may end up getting foo.php from Server1 and then being redirected to Server2 for bar.php. I am concerned that this will break the Facebook auth session.
Does anyone know how I can correctly code for this scenario or if there are any best practices published anywhere?
The access token will be valid across both servers, you can even take the access token an use it in your own browser while it is valid.
I would store the access token in an encrypted cookie, that way every server would be able to obtain the right access token for the user.
i had enabled enable_single_sign_out: true.
I have two application, one in Rails, other in Django,
I want that when i login to one application, i would just go an refresh my other application and i would signed in automatically.
Sam way, if i singout from one application, and refresh other application i would sign out from it also.
How to implement this scenario with rubycas-server.
Currently when i login to one application and go to second and just click on login, it will automatically login. But i have to explicitly logout both applications separately.
I don't know about the Django client (the rubycas-server docs say that currently not all client applications support single sign out) but in order to get the Ruby CAS client to support single sign out you need to do the following (in the client app):
The Rails session store must be set to ActiveRecord:
config.action_controller.session_store = :active_record_store
The server must be able to read and write to RAILS_ROOT/tmp/sessions. If you are in a clustered environment, the contents of this directory must be shared between all server instances.
Cross-site request forgery protection must be disabled. In your application.rb: self.allow_forgery_protection = false. (Or rather you may want to disable forgery protection only for actions that are behind the CAS filter.)
Further information can be found here: https://github.com/gunark/rubycas-client#readme