I am using Glimpse for tracing web request. I have made below setting in Web.config on testing server.
Web.Config
<runtimePolicies>
<ignoredTypes>
<add type="Glimpse.AspNet.Policy.LocalPolicy, Glimpse.AspNet" />
<add type="Glimpse.Core.Policy.ControlCookiePolicy, Glimpse.Core"/>
</ignoredTypes>
</runtimePolicies>
so I able to run Glimpse on All client machine without making On/off from Glimpse.axd
My Question is Currently it is showing me browser name as Client Name , how can I show User name as Client Name like User1, User2 in Client.
The Glimpse.axd does not only allow you enable/disable Glimpse (which in your setup is not needed anymore), but it also allows you to set the client name. This SO Question gives you more details about the how and why.
If you don't set it yourself explicitly, then at some point Glimpse will do this for you. Basically if Glimpse can't find a cookie named glimpseId as part of the request and it is allowed to set a cookie as part of the response (determined by IRuntimePolicy implementations), then it will create that cookie with the name of the logged in user as the value or, when no such user exists, it will create a name based on browser details sent with the request, which is what you are seeing.
Now the funny thing about this, is that this is exactly what you want, but the sessions are still named based on the browser being used. The reason for this is that Glimpse is activated out-of-the-box in your case, as the ControlCookiePolicy has been disabled and that the very first request you make to your application, lets say to log in, will already create that cookie as it cannot find that glimpseId cookie and its value will be based on the browser details sent with the request and not on the logged in user, as there is none yet.
So if you remove that cookie with developer tools of your browser for instance, and you make a new request as a logged in user, then you'll see your name as the session name (beware only for the subsequent requests, as processing of that request will set the cookie as part of the response)
You could also write that cookie explicitly as part of your log-on procedure to make sure it is explicitly set to the name of the user, even if the cookie already existed as part of the request.
One downside, the cookie is not linked to any user session, which means that if a user logs out or the session expires, then the Glimpse cookie still remains and each subsequent request will be labeled as if the logged in user made it, which might not be the case any longer.
I able to set Client Name setting Cookie glimpseId as below.
$("#UserName").change(function () {
var userName = $('#UserName').val();
document.cookie='glimpseId='+ userName +';path=/
;expires=Sat, 01 Jan 2050 12:00:00 GMT;';
});
I get help from below link.
What does "Set Glimpse Session Name" do?
Now my updated output as follow after login with Admin username.
Related
I have a react app and a nodejs server. I set a httpOnly-cookie containing a JWT for authentication. This works. The problem is: I need some logic client-side to check if the user is logged in. When the user logs in, I could store this "state" in-memory (eg. useState), but when the browser reloads, this state is gone (while the cookie is still there).
I'm tried using js-cookie but obviously this won't work because it's a httpOnly cookie.
How can I check - without doing a (test) axios request to my server - if the user is logged in, when opening the react app in the browser?
Edit:
The answer in this question recommends to store the token in LocalStorage, but other resources (lik the discussion in the answer of this question) says cookies are the way to go.
to be clear, I don't need direct access to the token in the cookie, the cookie is send with every axios request ({withCredentials: true}) and it works like expected. But I just need to know if the cookie is set (and so the user is logged in).
There can be multiple approaches for this scenario. What I think you can do.
1 - You can send a http request to check if the JWT is valid on initial app load and whenever app is reloaded (Same thing basically) and then preserve some authentication state inside the app (Context Api or Redux) and this way you control the routes, etc.
2 - Make sure that whenever the JWT is expired you clear the cookie and whenever client receives 401 you refresh whatever authenticated state you have and redirect the user to login page or any page that does not need authentication.
Just to add to the selected answer.
a loading component and an isLoading state will help prevent the split-second showing of authenticated / protected screens. ex, isLoading ? <LoadingComponent /> : <ProtectedComponent />
You can just update the isLoading state when the request finishes, and should the request yield an unauthenticated response code, you can then perform a redirect.
I have a question about Sessions and Cookies on Node regarding where they are stored and how they work.
To begin with, I understand the following to be true:
With a cookie, it is possible to specify how long it will store your data;
A session saves data while the browser is open;
Cookies are on the client side;
Session is on server side;
Then the following questions arise:
How does the browser and/or the server know that the user has already
logged in and does not need to log in again?
If the Session stays inside a cookie what's the difference?
Where are cookies stored? In the web browser?
I use the (Blackberry?) passport (browser?) but it does everything by itself. I want to better understand how it works behind the scenes.
My affirmations can be wrong. You can correct me, but please explain to me.
Regarding what you understand to be true:
Yes, when setting a cookie, you can specify how long it will persist. In the article HTTP Cookies in Node.js, see the section entitled
"Adding Cookie with expiration Time".
Yes, data can be stored in a
session if it is explicitly placed there by application code. Your server software may also use it to store other information. Here
is a nice short YouTube video on node.js sessions.
Cookies are stored in a file on your computer which is managed by your web
browser, so again, correct. Here's a nice article that explains in more detail: Cookies - Information that websites store on your computer.
As to your other questions:
How does the browser and/or the server know that the user has already
logged in and does not need to log in again?
It generally knows this by storing a cookie in your browser whose value is some sort of session ID that acts as an authentication token. When you are successfully authenticated, it will store a cookie and send this cookie's value as an HTTP header or as part of the URL string, etc. each time you make a request to the server. This token is stored on the server with some sort of expiration time, usually something like 15-60 minutes. The expiration timer is reset to zero with each successful request. If session timeout is 30 minutes for example, the token will be invalid after no request is made within 30 minutes. Therefore, if you walk away from your computer for an hour and try to access another page, you will likely be told you need to log in again.
If the Session stays inside a cookie what's the difference?
As I stated in the answer to the previous question, an authentication token is generally stored as a cookie and sent with each request. It's good to use over and over until the session times out.
So, the difference is: A session is stored on the server. A cookie is stored as a file on your computer by your browser. A session cookie is stored on your computer which is used by the server to track individual user sessions.
Where are cookies stored? In the web browser?
Yes, as stated above, cookies are stored in a file on your computer which is managed by your web browser. See the article I linked to above for more detail.
First off, some general facts.
A cookie is stored in the browser and then sent back to the target server with every request to that server.
A cookie can either contain actual state data (such as backgroundColor=blue) or it can just contain a token that only means something to the server.
Whoever sets a cookie decides how long they want it to last before it "expires". If the server sets the cookie (as cookies can also be set from within Javascript in the web page), then the server decides how long they want the cookie to last.
A server session consists of the server creating a unique token and putting that in a cookie that it sets for that browser. In parallel, it also creates a session object that is stored on the server and it creates a means of associating the token with a particular session object such that when a request comes in and it has a particular token in it, the server can find the corresponding session object.
Note, sessions don't have to use cookies. They can also put a session id in the URL itself and that is occasionally used, but isn't very popular for a variety of reasons.
How does browse and / or server know that the user has already logged in and does not need to log in again?
A server can consider a browser to be already logged in if it finds an appropriate cookie in the incoming request and if it finds an associated session object in the server-side session store and if that session object is both logged in and not expired.
If the Session stays inside the cookie why is this difference?
Usually, when using server-side sessions, all that's in the cookie is a unique token - not any of the actual session data.
Where is the cookie stored? In our browser?
Yes, it's stored on your hard drive by the browser and then sent as an http header along with every request to the server that the cookie is associated with.
I have kind of a strange problem. I have build a web application in Lucee. You need to login to use web application. It has happened, at least twice, that a login session has been transferred to an other user. To clarify what happen:
User 1 is logged in the application, the session is active
User 2 goes to the web application and is automatically logged in and sees "welcome to the application user 1".
As mentioned above this has happened at least twice since the application is live, so it sounds like an incident. Security wise this is a big problem because user 1 is an administrator and user 2 has a basic access profile.
My question: does anyone recognize this issue and can someone give my some advice how to troubleshoot this problem.
Thanks
If you are using session variables, this could happen with data being assigned to the incorrect scope in a CFC or with objects being stored incorrectly in the application scope or even a mash-up of both.
Make sure that your CFC functions are using the function local scope:
var x = "" or local.x = ""
otherwise, x will be in the variables scope of the CFC, where it can be manipulated by any function inside the CFC. This leads to data bleeding from one call to another across sessions. Try using varscoper to scan your code for these issues.
Alternately, you could store an object that contains data for a user into the application scope or inside another object which is stored in the application scope. This could allow User A to access data meant for User B when they are logged in at the same time.
You need to do an audit of your code base for issues like this and go through your user session logic to verify where and how data is stored and accessed.
Like one of the comments suggested could be the users were on the same network and/or they used a proxy such as squid which would cache all incoming content. To check to see if it's a possibility take a look at the headers being sent out by your server and see if there are any headers related to caching (Cache-Control, Expires, Last-Modified, ETag).
if you want to prevent caching you could set the first example header in you application.cfc onRequestStart or to at least prevent user content being cached you could do some variation of the second example.
<cfscript>
//EX 1
header name="cache-control" value="no-cache"; //no caching by anything
//EX 2
if(loggedIn){
header name="cache-control" value="private, max-age=<time_in_seconds>"; //allow browser to cache content
}else{
header name="cache-control" value="public, max-age=<time_in_seconds>"; //allow anything to cache content
}
</cfscript>
I have been asked to use J2EE Variables and not store the CFID and CFTOKEN in cookies, as the CFID is reported as non-compliant: Predictable Cookie Session ID's Reported by Compliance Tests
In my Application.cfm, I have added setclientcookies="false". This stops the CFID and CFToken being written as cookies.
In the ColdFusion Admin, I have enabled J2EE Session Variables
So I now have a cookie with JESSIONID, and a session variable with URLToken containing CFID and CFTOKEN. However, every time I refresh the page, the CFID and CFTOKEN change. They do not persist as they did before. Which mean our admin login system fails.
I have done my own googling, but have found nothing so far. One suggestion I found was to write code to persist the CFID and CFTOKEN. However, this doesn't feel like a good solution.
Any suggestions?
Barebones Test
I installed CF 10 Developer Edition and enabled J2EE Session Variables
Created an Application.cfm with
<cfapplication name="test" sessionmanagement="Yes" setclientcookies="false">
and an index.cfm with
<h1>Cookie</h1>
<cfdump var="#cookie#">
<h1>Session</h1>
<cfdump var="#session#">
The Session.URLToken changes with every refresh
CFID=2212&CFTOKEN=41db974c3d2eb4b6-640C21AE-FD53-499C-71FBEBA35D6B09E8&jsessionid=E28AA17629928FB6F9E17674AC85C7AA.cfusion
CFID=2213&CFTOKEN=bb791a304929d0f5-6425021B-A31B-B9C8-3628AE391B0F48FF&jsessionid=E28AA17629928FB6F9E17674AC85C7AA.cfusion
Further Thoughts
The CFIDand CFTOKEN are used in our login system to verify the user session matches, maybe I should change it to store and verify against the JESSIONID. Maybe it doesn't matter that the CFIDand CFTOKEN change. The session scope is actually maintained, so this could be a completely non-issue.
<cfparam name="session.timestamp" default="#now()#">
setClientCookies="false" means that coldfusion server will not create cookies for the current session. CFID and CFToken will still exist and will be non-persistent.
Check in your example that jsessionid value is same in both cases and that is what you should use instead of CFID & CFToken only if need be.
And you are correct, your session state is maintained as you have enabled J2EE session variables.
I'm fairly new to website development. I'm working on a site where the user logs in with username/password, and gets a sessionID from the server in response. This sessionID is sent back to the server (and a new one returned) with each request.
I'd like the site to work properly if the user opens it in multiple tabs or windows. i.e. once logged in at one tab, opening a members-only URL in another tab works without loggin in. (And, logging out in one tab logs out from all.) I see no way of doing this without storing the latest sessionID in a cookie. That way the latest sessionID can be "shared" among all tabs.
However I am starting to read up on cookies, and some of the security threats. I was unaware that cookies were sent with every request. I don't need to send my cookie to the server, ever. The sessionID is added to the xhr request's headers -- not read as a cookie. So I'm wondering if there is a way to disable sending of this cookie. My only purpose for it is to allow multiple tabs/windows in the same browser to share the same session.
I was reading up on the path parameter for cookies. Apparently this can be used to restrict when the cookie is sent to a server? What if I set the path to something that would never be used? Would this prevent the cookie from ever being sent out automatically? I only want to access it from JavaScript.
A coworker has put a lot of safeguards into the server-side of this application, which I won't go into here. So this question is just about what client-side precautions I can and should take, particularly with cookies, for optimal security. If there is a better way to allow a members-only site to work properly with multiple tabs open at once, I'm all ears.
I discovered just now that in HTML 5 there is local storage, which stores key/value pairs much like a cookie, but is not sent with every server request. Since it's supported in every browser except IE 7 and earlier, I'll be switching to this to enable sharing data between tabs when available, and use cookies instead on IE 7 and earlier.
The sessionID is stored in a cookie already there's no need to manage it. Because the HTTP protocol is stateless the only way to maintain state is through a cookie. What happens when you set a session value the server will look up the dictionary of items associated with that cookie id (session Id).
What is meant by stateless is that between requests HTTP does not know if your still alive or have closed your browser. Therefore with each request the browser will attach all cookie values to the request on the domain. SessionId is stored in the cookie automatically when they go to your site. The Server then uses that value to look up anything you've set in the users session.
Depending on which programming language and/or server you're using the session could be handled differently but that's usually abstracted away from the programmer.
Now with respect to sessions, there are a number of different things that make them insecure. For example if an attacker were able to get their hands on your session cookie value they could replay that cookie and take over your session. So sessions aren't a terribly secure way of storing user information. Instead what most people do is create an encrypted cookie value with the users details, the cookie could be a "session cookie" meaning as soon as the user closes their browser window the cookie is thrown away from the browser. The encrypted cookie contains user information and role information as well as some identifier (usually the clients ip address) to verify that the user who is submitting the request is the same user the cookie was issued to. In most programming languages there are tools that help in abstracting that away as well (such as the ASP.NET membership provider model).
Check out some details on the HTTP protocol and HTTP cookies on Wikipedia first
http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
http://en.wikipedia.org/wiki/HTTP_cookie
and check out the membership provider model on ASP.NET, it's a really good tool for helping to secure your site.
http://msdn.microsoft.com/en-us/library/sx3h274z(v=vs.100).aspx
Preventing the browser sending cookies seems to defeat the object of using cookies in the first place.
If you don't want the sessionID to be sent with each request, why set the cookie? A better solution would be to use a custom response header that you send from the server to the browser - this will then be under your control and will not be sent automatically with all browser requests. You are using request headers to send your sessionID anyway so you could receive them from the server using a custom header and read this into your JavaScript from each XHR.