The domauthsessid cookie is created when a person logs on to domino server. I have also seen a cookie for sessionID when dealing with xpages. Is sessionID specific to xpages? How is this sessionID used by xpages?
Taken from http://www-01.ibm.com/support/docview.wss?uid=swg27021314:
Q. Sometimes when XPage is submitted it adds SessionID to the URL and
some JavaScript stops working. What's that SessionID?
A. This is due to the way HTTP is working. HTTP is stateless so the
browser must pass an ID to the server in order to keep a session open
on the server. There are two ways for passing this ID.
1 - Passing the ID as part of the URL
2 - Passing the ID as part of the cookie from the browser
The second way is the preferred way. But for the first page the XPages
engine doesn't know if the browser that is connecting to the page is
supporting cookies or not, so it tries first by passing an ID and a
cookie. And on the second request it looks for the cookie, and if the
cookie is there it removes the ID from the URL. So if you look at all
the application servers they are all working like that. Now there is a
property in XPages that says 'assume that the client has cookie', and
in these cases do not use a session ID at all. So that would break
some browsers that do not support having cookies enabled.
The sessionID URL parameter is not used with Lotus Domino 8.5.3 - only with 8.5.2 and older.
Create a Xpage as the following:
<?xml version="1.0" encoding="UTF-8"?>
<xp:view
xmlns:xp="http://www.ibm.com/xsp/core"
rendered="false"
>
<xp:this.beforeRenderResponse><![CDATA[#{javascript:
var externalContext = facesContext.getExternalContext();
var request = externalContext.getRequest();
var response = externalContext.getResponse();
var currentContext = com.ibm.domino.xsp.module.nsf.NotesContext.getCurrent();
var session = request.getSession(false);
var sessionId = session.getId();
// flush the cookies and invalidate the HTTP session...
for(var cookie in request.getCookies()){
cookie.setValue("");
cookie.setPath("/");
cookie.setMaxAge(0);
response.addCookie(cookie);
}
session.invalidate();
// now nuke the XSP session from RAM, then jump to logout...
currentContext.getModule().removeSession(sessionId);
externalContext.redirect("?logout");
}]]></xp:this.beforeRenderResponse>
</xp:view>
and then create a link or Page Link to point to the above Xpage…
This will log you out and remove ALL cookies.
DISCLAIMER: code found on the net (kudos to that person) and this will not work for client certificate authenticated servers…
Why paste this answer so late in the discussion? Because I've looked for the answer and none of the above is working so for future references…
The sessionID cookie is used by XPages so that the server knows which session it dealing with so when you run some code like sessionScope.get(param) it knows which user's sessionScope to look at.
In addition, a session represented with sessionId should not be confused with session-based authentication.
domauthsessid cookie is used in single-server authentication. If you are using multi-server authentication, LtpaToken will be used for that purpose. This cookies persist your authentication session.
XPages session will be preserved when you login, logout or even login with a different user. An XPages session will only be deleted after a specific idle time whereas authentication session is deleted when you logged out.
The cookie manages the browser session for the server. If you do a ?logout, the sessionScope variables are not removed. You can use SSJS to clear the sessionScope map and logout, but that will only clear the map for the current NSF. If you remove the sessionID cookie, the XPages session is removed and all sessionScope variables for the whole server are removed. I added an snippet to the xSnippets OpenNTF site that does the logout and remove sessionID cookie.
Mikael Andersson Wigander shows us a nice solution how to logout from a Domino server. However, the ?logout parameter in the URL isn't always working.
We found out that the logout page from Mikael only logged out a user in the first attempt. The browser then caches this logout page and prevents the user from logging out the next attempt.
The following change of Mikael's solution will tackle this problem:
var appUrl = facesContext.getExternalContext().getRequest().getContextPath();
var url = appUrl +"?Logout&t=" + new Date().getTime() + "&redirectto=" + appUrl ;
facesContext.getExternalContext().redirect(url);
Call the Xpage using a parameter also containing the time in milliseconds:
<xe:this.href><![CDATA[#{javascript:"Logout.xsp?" + new Date().getTime();}]]></xe:this.href>
Now the user will be able to log out every attempt.
Related
Sorry guys, I'm really new to sessions and cookies and I'm trying to understand the mechanism behind it. I wanted to add register/login to my simple website and in order to do I need to understand web authentication and I really think I will have tons of questions regarding this topic.
Initially, I have register page that sends info after clicking submit button to a node server using express.
I'm trying to see what happens, so I've created a session in post route, it's created in the browser (connect.sid), then I commented out the part that creates that session and just tries to redisplay the session object, but it's undefined, but I still can see the session in the browser's cookies section, so what's going on? Thanks
app.use(session({
secret:"my test secret",
cookie:{},
resave:false,
saveUninitialized:false
}))
app.post("/register", (req, res) => {
req.session.usertest = "testsession_hardcodedvaluefornow";
console.log(req.session.usertest); // -> this is okay when above line to create is uncommented
//but when I comment the session assignment, it becomes undefined?
res.send("In register...");
})
I can see the session cookie even after commenting out the create session and posting over and over.
connect.sid s%3A_TahsTv0xhY-iHIdjDRblYJ_aZZ5oiSd.do7JcOGR1FaXPcFFIQ6hg5AW%2B0XVsYwIRO8vndyjDzs
req.session.id produces a different value (not undefined) even if I delete my session in the browser, so not sure where that comes from.
There is no "usertest" key in the session object, therefore it is undefined. The reason it's not undefined when you uncomment that line is because you create that key yourself in that instant with that line.
You can get the whole session object by using req.session, the session id by using req.session.id and the session cookie by using req.session.cookie.
Edit
To further clarify: a session will be made for every connected client. That is why you can see the cookie in the browser. That has no meaning however, it's just a way to uniquely identify that client (without actually telling you who that client is). Any information about that session (whether they're logged in, user id,...) needs to be stored in a session store. Express-session will use memory store by default, if the server restarts all that information will be lost, which is why that key doesn't exist. In order to preserve that information it has to be stored in a persistent session store. More information on session store implementations for express-session and how to use them can be found here: https://www.npmjs.com/package/express-session
As for the cookie values you get, those are the default ones set by express-session since you haven't set any yourself. You can change the maxAge to let it expire (or set it so 10 years or more for a more persistent session), you can specify a domain to which that cookie belongs, you can set it to secure (to only allow it over secure connections, e.g. https) and httpOpnly is by default true. httpOnly cookies cannot be accessed/altered by the client (although you can see them in the browser), do not set this to false.
Have been working through the sails cast tutorials and am confused about the way that sessions work.
In the tutorial, the user is marked as authenticated in the session controller by:
req.session.authenticated = true;
req.session.User = user;
res.redirect('/');
Why is the session being saved in the request?! My understanding is that the 'req' object in express.js is the information the browser sends to the server.
Shouldn't the server save this information elsewhere (won't the request object be deleted when theres another request?)
Furthermore, somehow the application retrieves the authentication status from another object session when templating a page with ejs:
<% if (session.authenticated) { %>
why isn't this variable set directly?
Probably a silly question but I am confused at how the logic works and online articles/tutorials aren't helping me understand...
It is common practice for express middleware (remember, Sails is built on express) to attach properties to the req object so it may be accessed in later middleware, and eventually your controllers. What happens behind the scenes is your req object comes in with a cookie containing the session ID, and then the session middleware uses that to retrieve the actual session data from some datastore (by default, and in-memory store is used. Super fast and easy for development, but not recommended for deployment), and then attaches that to the req object.
Regarding the value of session.authenticated in your EJS, by default Sails includes req.session in res.locals (accessible in views), so that value will be whatever is stored in the session via your controller.
The browser sends over the session id which is stored on a cookie. The session object is referenced by that session id which is stored server side. The session is attached to the request (for convenience I suppose). You can read more here https://github.com/expressjs/session#compatible-session-stores
I wouldn't know what is setting session.authenticated without seeing more code.
I am using Express4 to develop a web app(a simple twitter).
I use npm package "express-session" to manage session and cookie.
But I did not set cookie.maxAge. Based on the git document we have:
By default cookie.maxAge is null, meaning no "expires" parameter is set so the cookie becomes a browser-session cookie. When the user closes the browser the cookie (and session) will be removed.
but actually, when I close my chrome and start it again, I still have the same cookie generated by server in last request.
Has anyone faced same problem? Thanks for help.
You can try:
// This user should log in again after restarting the browser
req.session.cookie.expires = false;
Each session has a unique cookie object accompany it. This allows
you to alter the session cookie per visitor. For example we can
set req.session.cookie.expires to false to enable the cookie
to remain for only the duration of the user-agent.
I am trying out express.session() middleware. The usage seems to be fairly simple and I quickly implemented what I wanted. Basically I implemented authentication based on session cookies. As a part of this function I implemented checkbox "remember me" which is pretty much a standard for login windows on the web. Here appears to be a problem.
I want the following functionality - when user opens/reloads the page if there is valid session cookie and it matches existing session object on server application, then session.cookie.maxAge on server and cookie expiration on client are reset to the new value (which is now() + x). Therefore making page work like - if user did not come back for e.g. 3 days then he is automatically logged out, but if he comes back within 3 days, then he is logged in and auto-logout counter is reset back to 3 days.
I expected that session.touch() would do it, but it only seems to reset session expiration date on server and doesn't push new cookie to client.
My question - did I miss something or it was intentional implementation?
PS: I could regenerate session each time and that would update cookie. But I concern for overhead of running this code on every request I also could manually push updated cookie, but would prefer to do it within express.session() functionality.
I also found this question which was never answered (except for OP himself):
Updating cookie session in express not registering with browser
"cookie.maxAge" is updated automatically by connect.session touch(), but only on server side.
The updating of maxAge on client side has to be done manually with res.cookie.
Eg.:
res.cookie(
'connect.sid',
req.cookies["connect.sid"],
{
maxAge: req.session.cookie.maxAge,
path: '/',
httpOnly: true
}
);
See this answer to the StackOverflow question you linked to above:
https://stackoverflow.com/a/27609328/4258620
For now Express-session should update cookies in browser, in code .
rolling: true in config provide your desirable functionality. It automatically performs touch on every request. Docs
I am building an HTTP server in nodeJS (homework assignment), and I need to manage HTTP sessions with cookies - for each session I send a cookie with UUID (string ID) and then when I get it back I reset the session's timer.
My question: should I open a session for each request (i.e. even an image/css request for example) or for each page?
This is my code now:
socket.on('data',function(data) {
//some code
// if no UUID exsit in request, create one for it
var request = new REQUEST.Request(data, resourceMap, rootFolder); //
//response will send the UUID created/sent in request
var response = new RESPONSE.Response(socket,request);
session(request); // look for uuid from request in data base
}
Right now when I load a page, the html request is always the first and a new UUID is created for it, but not for the next requests (images etc) in that page.
Also, when I hit a link to another page no UUID is created.
Any ideas why? Where is the best place to check for an existing UUID and add one if its not there? thanks!
You should create a session for one session. :) Not each request.
In the session you can set an UUID.
There are plenty of resources out there to help you. If your professor has allowed you to use libraries, I'd highly suggest checking your options. This is just a few: https://github.com/joyent/node/wiki/modules
Because it's homework question, I think it's best that you only get some direction to the 'answer'
Good luck