I am developing a simple application on Rails 3 using basic authentication.
The application checks for a valid session on every request. How can I manage sessions using Sencha? I tried to get the Rais Session to pass it as a param to sencha so it could send it back to the app.... but using request.session[:id] or *request.session[:session_id]* is not returning any value.
What would be the best way to approach this problem (keeping sessions)? I thought about creating my own session hash to use...
Any help is highly appreciated!
Ok, from the beginning - not request.session but just session. Not session[:id] but request.session_options[:id] (at least as described here: Finding the session id in rails 3 , works in rails4 as well).
How/Why do you want to manage session in Sencha? Sencha is fronend only, it has nothing to do. If yoy have properly configured session in config/initializer/session_storage.rb, then session_id should be passed in cookies on every request.
Related
As I am working on implementing a proper auth flow into a react web app, I am presented with different patterns of how to use access and refresh tokens.
I am considering the following two patterns:
Creating some sort of middleware to the fetch API:
This middleware runs before every request to the backend and checks whether the access token is still valid or not.
If it is invalid, it first calls the auth server to fetch a new access (and refresh) token.
Creating an interval which is independent from all other logic to keep the access token alive.
Say if the access token is valid for 5 minutes, the interval will run every 5 minutes to fetch a new access token
I would also make sure it only runs every five minutes, if the user is still active , so that the application left open without any user interaction for a long time will automatically log out
Any API call simply uses the currently active access token and does not need to worry about checking the token first or anything
The second approach seems much much easier and cleaner to implement for me, since it does not add any complexity to fetching data and is completely independent/seperate to the app otherwise.
I've been having a hard time to research this question though tbh. I'm not sure if there is some security issue I'm missing with that approach.
So my questions are:
Is there any security issue with fetching a new access token in an interval from the clients side?
Is there a common practise on how SPA apps (like the react app I mentioned) handle access tokens?
If yes, what is that common practise?
If there is no security issue, are there other cons of the second approach that I am missing out on?
Thank you for your answers in advance!
I think the answer depends, if you always do it every X minutes, and you have many active clients, it might create more load on the backend, compared do doing it on a need basis. Perhaps all clients are not so active all the time?
One thing to look out for is to make sure you don't trigger multiple requests at the same time to request new refresh tokens. If you get a race condition here, then you might be logged out (if you use one-time refresh tokens)
Also it is worth considering to use the BFF pattern, do watch this video
Using the BFF pattern to secure SPA and Blazor Applications - Dominick Baier - NDC Oslo 2021
I'm setting a session value in one app and it's not available in any other app once the redirect happens. It's available in the source app (the one where the value is set) though. Is this expected behavior?
I've inspected session IDs in the origin app and in the target redirected app and they are different. So how can/should I pass the session variables from one app to the next? I need this for setting the authenticated user and currently it doesn't work due to this behavior.
Kind regards
Seba
The problem was that I was using different session secrets for each app. When using the same session secret, it works as expected.
Seba
I'm using Ember-Simple-Auth on an Ember-CLI project, and I'm also using the provided ember-simple-auth-devise authenticator that comes with 3.1. I'm able to login and logout successful, but I can't figure out where's the best place to put the callback (or when the promise resolves) upon successfully logging in. I want to be able to use the data returned by my API on my app after logging in. Any suggestions and advice would be highly appreciated! If requested, I can also provide code samples (although I figured it wasn't necessary since what I have implemented thus far is nothing custom).
Thanks!
When the session is authenticated successfully, the sessionAuthenticationSucceeded action is triggered (see http://ember-simple-auth.simplabs.com/ember-simple-auth-api-docs.html#Ember-SimpleAuth-ApplicationRouteMixin-sessionAuthenticationSucceeded, there are also more actions for other events). So that's a good place to react to the session becoming authenticated.
As the authenticator will set all values the server responds with as properties on the session you could also define additional properties that depend on these - see example here (where the account property depends on the accountId property that's read from the server response): https://github.com/simplabs/ember-simple-auth/blob/master/examples/4-authenticated-account.html#L101
We are building ASP.NET MVC app that is supposed to manage sport objects reservations (tennis courts, squash courts etc).
Users are not supposed to act only in scope of one club at the moment of interaction with app.
Navigation to the app should be like:
appname.com/clubName or
clubName.appname.com
Questions:
1. What would be the best way to persist the data about selected club. We have implemented storing in session (injecting information about the club durint app opening), but we read that using session is rather deprecated solution. We are using ApiController so in order to get the session we had to hack the routing (registering custom RouteHandler). Is session mechanism applicable for this problem?
var session = HttpContext.Current.Session;
if (session != null)
{
service.ClubName = session[CustomSessionKeys.ClubName.ToString()].ToString();
}
Is it good idea to use subdomains for our problem?
Many thanks in advance :)
Generally a web api works differently than a normal mvc app.
In an MVC application you would use a session cookie to make the internet act like a state machine. However, this is not what is generally done for web api's. In a web api, you provide some form of authentication (e.g. via the header authentication field).
But within a request you ofcourse want to to keep track of the current user, or in asp.net terms, the current principal.
We set the principle though a Delegation handler
HttpContext.Current.User = user;
If you want some more code on how this whole authentication is done, just let me know.
This was all serverside ofcourse, on the client side, you can keep any information you want in a session store. Although you might want to consider using the local storage in stead (depending on what semantics you want to give it). They both work in the same way.
You can consult W3C webstorage specification for the complete information on both of these.
Well you have many choices I guess!
Go with the route thing as you suggested, where you keep the club Id or name as part of the URL. I would go for this if I need the link to give more meaning to the user.
Cookie! yes, if the information is not sensitive store it in a cookie. In case this cookie is only to be accessed from server side, then don't forget to make it HttpOnly
Session. I agree with you, I wouldn't choose session unless the data was very sensitive and I needed to make it secure.
In my Java web application,when a user gets logged in,i store the user name and other details in session as follows,
session.setAttribute("userName",username);
I am using ExtJs4 for UI.How to get the session variables in extJs?
Thanks
I can second #Geronimo approach. You need to get user Id and/or permissions when you authenticate the user. However...
You can't rely just on the username/permissions that you store somewhere in your JS code because it can't be easily spoofed. If you present user with some information that can be different for different levels of access you still need to do server side validation of the user identity.
You can't get session variables off the server web container using javascript only.
I do the same thing (storing userId as a session variable in java). I use Ext.Request to perform an Ajax request to a java servlet to get it (along with other data about the user like permission settings for the webapp to enable or disable features they wouldn't be able to use).
EDIT:
I second sha's answer also, the only reason I pass the authentication information back to the client is for cosmetic reasons - so that user doesn't think he can use a feature in javascript that would be denied by my server side authentication. If he were to spoof the userId or permissions and try to use the feature, the real authentication on the server side would stop him.
I understand that the question has been asked for a long time ago, but despite the large number of views and the absence of an plain answer, I decided to offer this answer:
Assume that the session variable is registered like /index.php?PHPSESSID=9ebca8bd62c830d3e79272b4f585ff8f
In this case, you can get the variable PHPSESSID through JS object "location" and transform it through Ext.Object.fromQueryString()
So:
console.log( Ext.Object.fromQueryString( location.search ) );
will prepare PHPSESSID variable for your needs.