I am trying to figure out how can we detect if we are logged in to a site from Firefox Extensions.
I am planning to invoke a rest api in the target site to detect if the user is loggedin or not. I am not sure what is the right place to make such calls.
Going though documentation, seems like main.js is could be the place where I want to put such method, but then I am not sure how to call form my views this particular method in main.js
There is no generic way to determine that a user is logged in to a site. Every site can, and does, choose their own method of doing so. The most common method is to store a session cookie on the user's machine through the browser. However, the specifics are nearly certain to be different at each site. There is also the question of, in your situation, if there is the possibility that the site permits the user to be logged in for an extended period of time (i.e. not just in a session).
The most probable way to successfully determine how the fact that the user is logged in is recorded on the machine is to look at the differences between what cookies are stored (for the site) prior to the user being logged in, while the user is logged in, and after the user is logged out. There are a large number of extensions dealing with cookies. One of them should probably be able to help with letting you look at the information you need to examine for this investigation.
Once you have that information, you can use a variety of different interfaces in Firefox to access the cookies and see if the user is logged in. Obviously, you will want to listen for changes, and/or listen for a page from the site to be loaded (overlay/bootstrapped, SDK) rather than pooling for changes in the cookies.
MDN refs about the cookie interfaces:
Deal with individual cookies:nsICookie, nsICookie2 nsICookieManager, nsICookieManager2
Deals with the entire cookie string: nsICookieService
Related
My question is about the MVC Antiforgery system (described here).
Consider a simple app which posts todos to /Todo/Create. The corresponding action method has the ValidateAntiForgeryToken attribute. Consider the following client workflow:
User A logs on and goes to the page to create a todo, but doesn't do it yet.
User B (physically on the same computer) opens a new tab in the same browser, logs out of User A's account, logs in as User B. The browser then gets User B's validation cookie.
Some time later, User A switches back to their original tab and hits 'create' on the todo they were making.
In this scenario, the Antiforgery verification will not pass because the form token was meant for User A, while the validation cookie is for User B.
I'm sure there are valid security reasons for this behavior (e.g. a script on another site that manages to login as malicious user so that the 'todo' data is posted to their account instead), but it doesn't stop the above scenario happening for my legitimate users sometimes.
My questions are:
Is there a 'best practices' way to handle this scenario? Is it usually just a case of showing a custom error, telling them to reload the page and/or login again etc?
Is there any way to know when the out-of-the-box MVC Antiforgery system runs into this error? It seems to only ever throw the same kind of Exception (HttpAntiForgeryException). Would I need to revert to using/modifying their source?
I see two ways of handling it:
Use Javascript callback to the server before hitting a button to detect if the user is still logged in. If not - display him a message. It should be relatively easy to do this. But it requires one additional call, and little bit more time to execute your request.
One solution to avoid callbacks could be using html 5 localStorage (and you can support that on other browsers using modernizr, for example). It is shared between tabs. But I'm not sure if this approach is good. Additional research required.
Catch HttpAntiForgeryException on the server, check if the user is logged in. If the user is not logged in, display him a message.
Usually approach (1) is used. On banking websites they detect with JavaScript when you logged out in other browser tab.
There's a subset of users which will not have access to the system I'm implementing in the beginning but I need a mechanism for them to capture data for one specific part of the process.
An authorized user creates the original record for a Person with some basic details i.e. First name, last name etc.
I then create a 'DataRequest' record which has a unique guid and the external user is sent an email with a path which is effectively http://sampleapplication/Person/Complete?guid=xxxx
The external user adds additional details like Date of Birth, Eye colour etc, submits and saves to the DB. The DataRequest for that guid is then expired and cannot be accessed again.
The Complete action doesn't have any authorization as these external users do not have user accounts.
My preference is to force these users to use the system but at this stage I'm not sure it's practical.
Is this a bad practice?
Should I be implementing some additional security on this like a one time password / passcode contained in the email? Are there alternative approaches I should consider?
There's nothing wrong with opening up a section of your site to the public. Tons of websites have secured and unsecured sections. However, there's also nothing saying that you have to expose your secure site at all. You can create another site that merely has access to that change those records and make that site alone, public.
As far as securing the information of the user, passcodes by email are the invention of some developer somewhere with limited mental ability or a severe lack of sleep. If the link is only available by email (not discoverable by search engines and not easily guessable), then anyone with the link will also have the passcode, making the passcode to access the link redundant.
You should however log when the email is used to finish the record and then disallow further uses.
I am using this answer here to log unique page views in my app: https://stackoverflow.com/a/15174466/1235816
I am using a cookie to check for unique visits. As far as I am aware, because the site will be hosted in the UK, I should have a message which asks the user to accept cookies or if they don't... it asks them to leave the site.
I want it to work like this... If a user wishes to accept cookies, then the 'app-name-visited' cookie should then be downloaded, otherwise if they just exit the site without clicking accept, no cookies are downloaded to the clients machine...
Is this:
1/. a correct way of thinking?
2/. possible?
The cookie law has since been modified, so this is not quite necessary any more, you only need to let the user know that they you will be using cookies.
The organisation that enforces this is the ico, which doesn't ask for permission for cookies on their site:
http://www.ico.org.uk/
Suggest you follow this pragmatic approach.
If you are wanting to comply as per your question I did some work on this a while back for rails projects which should be a decent starting point:
https://github.com/yule/threepwood
In may Rails web application, I need to enable more control in user authentication like if a user after registration will have specific credentials to login. So he/she should be able to login from a particular system(PC) only. This can prevent other users from logging in even if they know the particular users' credentials. Can we use Cookies for this purpose? Will Cookie always be unique if we access a particular web app from a particular PC? Help me to have a better solution.
Thanks in adv :)-
In my opinion, use cookies with caution, when you have no other options.
In this particular case (i.e. identify a unic computer), I think you can identify it by 2 solutions :
A stupid cookie with a value you know. The problem of a cookie is that a user can simply copy/paste the cookie value to another computer to have same access.
A unic key computed from computer data. You can create it with some accessible informations from this computer : browser, browser plugins, browser version, operating system, etc. This key can now be stored as a cookie. You have to check if this key is valid, regarding your identification function. Copy past have no effect because source informations are not the same. The main problem of this solution is it's 'too' secure : if the user change its browser, add a plugin, change its browser version, the function to compute key will not work at all.
This is the second solution I use, with this informations for example Rails Browser Detection Methods or https://github.com/josh/useragent
You can store secuirity token (md5 hash or something else) in the cookie, and check it for access.
We are attempting to integrate an ASP.NET MVC site with our client's SSO system using PingFederate. I would like to use the built in FormsAuthentication framework to do this. The way I've gone about it so far is:
Set up my Web.config so that my FormsAuthentication LoginURL goes to my site's "BeginAuthentication" action on a "Security" controller. From this action, I set up some session variables (what URL was being accessed, for example, since Ping won't send this info back to me), and then redirect to our client's login page on an external site (www.client.com/Login for example).
From here, the authentication takes place and a cookie is generated on the same domain as the one that our application is running on which contains the unique identifier of the authenticated user, I've set it up so that once this happens, the Ping server will redirect to my "EndAuthentication" action on my "Security" controller.
In this action, I call my membership class's "ValidateUser" method which takes this unique identifier from the cookie and loads in the user on our application that this ID refers to. I save that logged in user in our Session (Session["LoggedInAs"], for example) and expire the cookie that contains the id of the authenticated user that the SSO system provided for me.
All of this works well. The issue I'm wondering about is what happens after our user has already authenticated and manually goes back to our client's login page (www.client.com/login) and logs in as another user. If they do that, then the flow from #2 above to number 3 happens as normal - but since there already exists an authenticated user on our site, it seems as though the FormsAuthentication system doesn't bother kicking off anything so I don't get a chance to check for the cookie I'm looking for to login as this new user. What I'd like to do is, somewhere in my Global.asax file (probably FormsAuthenticate_OnAuthenticate), check to see if the cookie that the SSO system sends to me exists, and if so, sign out of the application using FormsAuthentication.SignOut().
Another issue that seems to be related is that if I let my Session expire, the FormsAuthentication still seems to think I am authenticated and it lets me access a page even though no currently logged in user exists in my Session, so the page doesn't render correctly. Should I tap into the Session_End event and do FormsAuthentication.SignOut() here as well?
Basically, I want to know when the authentication ticket created by
System.Web.Security.FormsAuthentication.SetAuthCookie(..) gets checked in the flow of a request so that I can determine whether I need to SignOut() and force revalidation or not.
Thanks for any help. Sorry for the length of this message, trying to be as detailed as possible.
Mustafa
Welcome to the small section of Hades that is mixing session with formsauth.
If your needs are as complex as presented, you would get more sleep if you implement a full provider stack to share amongst the participating sites. Easier said than done, I know.
But to address your question:
from http://www.codeproject.com/Articles/39026/Exploring-Web-config-system-web-httpModules.aspx
On the way in....Check ticket and set identity #
app.AuthenticateRequest += System.Web.Security.FormsAuthenticationModule.OnEnter-->OnAuthenticate
On the way out... set the ticket and redirect as necessary
app.EndRequest += System.Web.Security.FormsAuthenticationModule.OnLeave
Reflector is your friend. ;-)
I don't know about a specific event for when the cookie is checked, but you could place the appropriate logic in Application_BeginRequest() and check the user's authentication state there.
Another issue that seems to be related
is that if I let my Session expire,
the FormsAuthentication still seems to
think I am authenticated and it lets
me access a page even though no
currently logged in user exists in my
Session, so the page doesn't render
correctly.
The life of the cookie (how long until ASP.NET feels it needs to ask for a password again) and how you are managing state are unrelated. The ASP.NET authentication is cookie based so that, should a developer want to, he could turn off viewstate, session, use no query strings or hidden fields and authentication still works.
If you want to tie the interval at which you request the password to how you are persisting data, then you will want your session expiration to be roughly the same as the cookie expiration, but they will never quite match up. It would be better to have two policies (one for how fast you throw away a users session data and one for how long you are willing to wait before you need to reask for a password)