In the latest Meteor release (version 0.5.8), Session has been removed from the server-side code.
Previously I've used Session to store client-specific variables for the server; what is the replacement for this functionality?
Example case: User One opens a browser, User Two opens a browser. One calls a method on the server setting some token, the other calls a method on the server doing the same. I then need to access this when the client requests something. How do I differentiate between the two?
You'll want to save your tokens to a collection in the database.
You could use a Session on the server if you wanted to simply by copying the session package into your application's packages directory and changing its package.js to also load on the server. But a Session is an in-memory data structure, and so won't work if you have multiple server instances; and you wouldn't be able to restart the server without losing your user's tokens.
If you store your tokens in the database they'll persist across server restarts, and will work with a future version of Meteor which is able to scale an application by adding more server instances when needed.
If you need to expire your tokens (so that your collection doesn't grow without bound), you could add a "lastUsed" Date field to your token collection, and periodically remove tokens that haven't been used for longer than your chosen expiration period.
You can use each one's session id which is unique to the tab too. Not too sure how to get the current session id but it should be there somewhere (you can see it in Meteor.default_server.sessions, so there is still a way:
Client js
Meteor.call("test", Meteor.default_connection._lastSessionId, function(err,result) {
console.log(result);
});
Server side Js
Session = {
set : function(key, value, sessionid) {
console.log(Meteor.default_server.sessions[sessionid]);
if(!Meteor.default_server.sessions[sessionid].session_hash) Meteor.default_server.sessions[sessionid].session_hash = {};
Meteor.default_server.sessions[sessionid].session_hash.key = value;
},
get : function(key, sessionid) {
if(Meteor.default_server.sessions[sessionid].session_hash)
return Meteor.default_server.sessions[sessionid].session_hash.key;
},
equals: function(key, value, sessionid) {
return (this.get(key, sessionid) == value)
},
listAllSessionids: function() {
return _.pluck(Meteor.default_server.sessions, "id");
}
};
Meteor.methods({
test:function(sessionid) {
if(!Session.get("initial_load", sessionid)) Session.set("initial_load", new Date().getTime(), sessionid);
return Session.get("initial_load", sessionid);
}
});
I hook into Meteor.default_connection._sessions to store the values so that theres some type of garbage collection involved when the session isn't valid anymore (i.e the user has closed his tabs) to prevent memory being wasted. In livedata_server.js these old sessions get destroyed after 1 minute of no activity on the DDP wire (like the heartbeat).
Because the server can see everyone's session you can use the sessionid to access another user's session data. and listAllSessionids to give out an array of all the sessionids currently active.
Automatically set session like this.userId in a Method without using a param in a call
It looks like there is functionality for this this but its not fully hooked up. The session id would be stored in this.sessionData but its likely still unfinished. Its there to be called in method but theres nowhere that its being set yet (in livedata_connection.js & livedata_server.js)
Related
In spring boot application only one user should be using the certain page at a time (let's call it home.jsp). Another users should be redirected to different page(let's call it another_home.jsp) if they appear when accessing that same url. User doesn't login and just uses the application as it is. Any policy can be used for home.jsp could be first-come-first-serve or any other.
If more than one users are using application at a time only one user should be using home.html and all rest of the others should be using another_home.jsp.
As no login is needed in the application I believe I need anonymous sessions. Also, session needs to be expired after some time of inactivity. I've searched spring security but couldn't find anything.
I think that you don't even need spring security. Simple http session will work too. As far as I can see you just want to allocate the stream to one user and for that you need first user's session id which you can compare against whenever the requests come again. So store session id and expire after some timeout with some Time object or Date object.
In properties
server.servlet.session.timeout = 600 // 10 minutes
Something like this
private String currSessionId = null;
private Date lastDate = new Date();
private Integer TIMEOUT = 600000; // 10 minutes
public String loadHomePage(Model model) {
if(currSessionId!=null && new Date().getTime()- lastDate.getTime()>TIMEOUT){
currSessionId = null;
}
if(currSessionId==null){
currSessionId = session.getId();
lastDate = new Date();
return "home";
}else{
if(session.getId().equals(currSessionId)){
return "home";
}else{
return "another_home";
}
}
}
This is as simple as it gets when you don't have logged in users to manage and also don't need to remember previous state where user left off. Let me know if it helps.
You need to create a serverside state that is either empty or stores the identifier of the visitor that is currently claiming /home.jsp.
This could be a field on a singleton Bean, or an entity in the database.
It has to expire automatically, or it will prevent new visitors forever to make a claim.
As long as the state is empty, the first visitors identifier will be stored in this state.
And from that moment on, you will redirect all other visitors to another_home.jsp
So the Controllers Code would be something like this
if(visitorHoldsTheClaim()) {
return "home.jsp"
} else if (noClaimActive()) {
createClaimForVisitor();
return "home.jsp"
} else {
return "redirect:/another_home.jsp"
}
Depending on your implementation, these methods will do different things.
I'd usually recommend against serverside session state (more about this in Roy Fieldings Dissertation),
but for your use case, you need a way to identify a visitor over many requests.
A session would certainly be a very simple way to achieve this.
You can at least minimize session usage by only creating one session at a time - the one for the visitor that holds the claim.
In this case you'd never have more than one open session, and the visitor that owns the session is the visitor that holds the claim.
So in this case, the implementation would be be something like this:
if(currentUserHasASession()) { // checks if the current user has a session, but !!!does not create a new session if it does not exist!!! careful, HttpServletRequest.getSession(true) would create it!
return "home.jsp"
} else if (serverHasNoSessions()) { // https://stackoverflow.com/questions/49539076/how-can-i-get-a-list-of-all-sessions-in-spring
createSessionForUser(); // HttpServletRequest.getSession(true)
return "home.jsp"
} else {
return "redirect:/another_home.jsp"
}
Keep in mind that this only works if you do not create Sessions in another place.
So you have to configure Spring Boot/Spring Security to not create Sessions. How to make spring boot never issue session cookie?
Also keep concurrency in mind. For example, if you had only one server instance, you could put this code into a synchronized method to avoid two visitors creating a claim at the same time.
So... first of all, this sounds like a bad idea. I would be curious why you would need such an unusual behavior. There might be more sensible approaches for it.
Like Gregor said, the redirect code part is rather straightforward:
if(pageLock.getUser() == null) {
pageLock.setUser(user);
}
if(user.equals(pageLock.getUser())) {
return "home.jsp"
} else {
return "redirect:/another_home.jsp"
}
What is actually more tricky is the part when "expiring" the lock. It's likely the user will simply close the browser and not click on "logout" (or whatever), leaving the lock forever. On the other extreme, the user might be gone for a lunch break but its browser still has the page open for hours.
So that's the first thing you wanna add: some keep-alive mechanism on the page, regularly prolonging the lock, and some expiration checker, releasing the lock if nothing was received for a while.
...but like I said in the beginning, the whole thing sounds fishy.
This question applies to a Lucee 5.x application. I'm not sure if there are differences between how ACF and Lucee handle session scopes across a cluster.
Background: I'm implementing an autoLogin() function in application.cfc - in onRequestStart() - that looks for a token that's stored in a cookie, and then uses it to authenticate the user. Once a token has been used, it gets replaced with a new value, and the cookie is updated. When a token is not found or doesn't work, the cookie is deleted. A session lock is used to prevent multiple concurrent requests from attempting to login the user, which would have unintended side effects.
All the core functionality for this works (on a single node), but I need to make it cluster-friendly. The cluster is already setup correctly (this.sessionCluster = true; in application.cfc, along with a shared Memcached instance that stores session data), and it works fine.
The main questions I have are: (referencing the code below)
The code below uses an exclusive session lock to prevent concurrent requests from executing the login code at the same time. How would you replace the session lock below with one that locks the session across the whole cluster?
The code below assumes that changes to session variables can be seen immediately. Is this true when a session variable is changed on one node, and then a concurrent request on another node tries to access that same variable? If not, is there a way to refresh the session scope to ensure you're getting the latest?
Below is the autoLogin() function: (works on a single node)
private void function autoLogin () {
// multiple, concurrent requests could be hitting this on different nodes in the cluster
// if we're already logged in, nothing to do
if (session.isLoggedIn) {
return;
}
// get the auth token if it exists
var token = cookie.keyExists("auth") && isValid("uuid", cookie.auth) ? cookie.auth : "";
if (token == "") {
// if a token doesn't exists, nothing to do
return;
}
// assertion: user is not logged in and an auth token exists
// attempt to login using the token, but make sure that only one
// request does this at a time - wrap with an exclusive session lock
// lock the session - how would you do this on a cluster?
lock scope="session" type="exclusive" timeout="10" throwontimeout=false {
// check if logged in again - another thread may have succeeded while this
// thread was waiting for the lock to open
if (!session.loggedIn) {
// we can only call this once if user is not logged in!
application.auth.loginWithToken(authToken=token);
}
}
} // autoLogin()
I am using Redux and would like to store some state on local storage.
I only like to store the token which I receive from the server. There are other things in the store that I don't like to store.
The workflow that I found on google is to grab from local storage in initial store map.
Then he uses store.subscribe to update the local storage on regular interval.
That is valid if we are storing the entire store. But for my case, the token is only updated when user logs out or a new user logs in.
I think store.subscribe is an overkill.
I also read that updating local storage in reducers is not the redux way.
Currently, I am updating local storage in action before reducer is updated.
Is it the correct flow or is there a better way?
The example you found was likely about serializing the entire state tree into localstorage with every state change, allowing users to close the tab without worrying about constantly saving since it will always be up to date in LocalStorage.
However, it's clear that this isn't what you are looking for, as you are looking to cache specific priority data in LocalStorage, not the entire state tree.
You are also correct about updating LocalStorage as part of a reducer being an anti-pattern, as all side-effects are supposed to be localized to action creators.
Thus you should be reading from and writing to LocalStorage in your action creators.
For instance, your action creator for retrieving a token could look something like:
const TOKEN_STORAGE_KEY = 'TOKEN';
export function fetchToken() {
// Assuming you are using redux-thunk for async actions
return dispatch => {
const token = localStorage.getItem(TOKEN_STORAGE_KEY);
if (token && isValidToken(token)) {
return dispatch(tokenRetrieved(token));
}
return doSignIn().then(token => {
localStorage.setItem(TOKEN_STORAGE_KEY, token);
dispatch(tokenRetrieved(token));
}
}
}
export function tokenRetrieved(token) {
return {
type: 'token.retrieved',
payload: token
};
}
And then somewhere early on in your application boot, such as in one of your root component's componentWillMount lifecycle methods, you dispatch the fetchToken action.
fetchToken takes care of both checking LocalStorage for a cached token as well as storing a new token there when one is retrieved.
I'm working with an ASP.net MVC3.0 application and I keep Current User information in the Session of Current HttpContext.
As I know HttpContext.Current is for per current request.Therefore, my Session data should clear after the new request.However, I can receive Current User session data from request to request by storing HttpContext.Current. I did this sample for testing purpose to understand the session management in MVC 3.0.
My question: How I receive session data after current request ? I really appreciate your help.
public static UserAccountDto CurrentUser
{
get
{
if (HttpContext.Current == null)
return null;
if (HttpContext.Current.Session[CurrentUserSessionVariable] != null)
return HttpContext.Current.Session[CurrentUserSessionVariable] as UserAccountDto;
return null;
}
private set { HttpContext.Current.Session[CurrentUserSessionVariable] = value; }
}
HttpContext.Current is not the same as:
HttpContext.Current.Request
the last one is different at every request, the first one contains members like User, Session, Server etc that are in many (but not all) cases the same request after request.
what you have done is correct the session variable you have create will be available for all the request following the one that creates it.
The HttpContext is one of the largest object you will find in web development and behind the scene is does lots of stuff. The reason why you don’t lose the session between the requests is because the server will keep it alive. You will be surprised to know that behind the scene the session uses the particular section of the cache
Sorry, I wrote a lot to explain my situation, If you don't have time or not in mood to read all these just jump to the questions. Even answering one of them helps my situation, thanks :D
I'm trying to write a web application in node.js, but since I'm too new to web, I don't know how to write the web login system. I don't want to use basic or digest http authentications, I want it like normal login systems with http forms and different pages shows different content for different types of users. I searched a bit, I know the basics, but they're not enough.
This is what I got:
We check the user and pass from the
POST data in the database
If correct we give the client a new session, and save it in a database.
The client saves the session as a cookie and sends it in each page request.
The server checks the session and gives the content intended for the user.
Here's the part I don't know:
How do we generate a session?
How do we send it to the client?
How is it saved in cookies?
When is it supposed to expire?
What happens if it is expired? What
should we do?
Is there anything else that I should
know?
If you can please, give me some examples in node.
Thank you in advance :D
A session is simply a unique key (session ID) associated with an object/array, this way you can connect data to a user of your site.
You send the session ID to the client as a cookie, once sent, the client sends its session ID to your server with every HTTP request.
You send the HTTP Set-Cookie header (Set-Cookie: sessionid=abcdefg38974).
You can make it expire when you want it to, when the browser closes or after for example a year (this would keep you logged in for a year, after which you'll have to login again).
When a cookie expires it is simply thrown away, on the serverside it will just look like the user doesn't have a session ID set yet so he has to log in again.
You should know of things like session hijacking (stealing someone else's session ID). Have a look at it.
Little example, it might increate the visit number twice each time you request because your browser also requests /favicon.ico. Keep in mind that this example is not very safe as session hijacking is possible, this also keeps all sessions in memory and forgets them when the server is restarted. It would be wise to save sessions to a database.
var http = require('http');
var sessions = {};
http.createServer(function (req, res) {
var ssid;
var session;
if (req.headers.cookie) {
// Cookie already set, read it
var parts = req.headers.cookie.split('=');
ssid = parts[1];
// Is the session id known to us?
if (typeof(sessions[ssid]) != "undefined") {
session = sessions[ssid];
console.log('Loaded session with id ' + ssid);
}
}
if (typeof(session) == "undefined") {
// No cookie set, make one
ssid = Math.random();
session = {
'visitNumber': 0
}
console.log('Created session with id ' + ssid);
}
session.visitNumber++;
// Respond to the browser
res.writeHead(200, {
'Content-Type': 'text/plain',
'Set-Cookie': 'ssid=' + ssid
});
res.end('Visit number: ' + session.visitNumber + '\n');
// Save the changes we have made to the session data
sessions[ssid] = session;
}).listen(8080);