Web-browser needs again username and password - c#

While a web page -which needs login- is opened in my browser,
if I close browser and re-open, I have to write username password again.
But, sometimes when I close browser and re-open for the same page, it isn't needed username and password again?
Is it about Session, Cookie? If yes, why are there different conditions?
What do you think?

Gokturk
Its depend on which they session state management technique are used. basically there are 3 state management can used in asp.net
Asp.Net state management
i think webpage using Cookies with some Expiry period. if its session then when u close the
browser then session will be cleared. (InProc Mode).
Cookie will expire for mentioned period, if u able to relogin after browser closed then the cookie is checked for your credentials.
for the different condition following the reasons will make point of it
if u cleared your browser data (sessions, cookies, etc)
u may clicked rememberd password, which would stored in Browser cache.

So it definitely seems the web site only allows session-based, non-persistant cookies. My guess (as I've seen this on my system as well), the browser is closed, but the process hasn't died off. When you open a "new" browser, it's picking up the existing process with all of the session information still valid. To confirm this, each you close the browser, check Task Manager to ensure iexplore.exe, chrome.exe or firefox.exe are completely missing before starting a new session.

Related

Clearing browsing data in chrome custom tab

Is it possible to clear browsing data, cookies, active logins, etc. behind the scenes(programatically) on chrome custom tabs?
My goal is to have the user be prompted to login every time they open the custom tab (instead of being logged in automatically)
Shared cookie jar and permissions model so users don't have to log in to sites they are already connected to, or re-grant permissions they have already granted.
Chrome Custom Tabs is the Chrome browser (via the Chrome service and custom Intents) and thus the cache, cookies, etc.. are shared (actually the same).
The answer is no, you can not programmatically clear the data of Chrome.
Note: Right now there is no support of creating an Incognito-based Custom Tab
I would issue the user a transient/session cookie so it does not get persisted if you wish to forced a re-login on the start of every new session.
"My goal is to have the user be prompted to login every time they open the custom tab (instead of being logged in automatically)"
As of now July 2020, on appauth's request builder you can use the method setPrompt(AuthorizationRequest.Prompt.LOGIN)
This will prompt the user to login every time.
If this method isn't provided and let's say there is some persistence needed (to log the user in automatically after they have logged in). If the server issues cookies to do this Currently it is a challenge to log the user out using an endpoint

FormsAuthentication logout issue

I have a problem with this scenario using FormsAuthentication
I access a website with my login and my password, the system make login using FormsAuthentication. After that I copy the cookies from browser.
I paste the cookies in the other browser and click F5, The system authenticate the user and access, after that I make a logout.
I turn back to the first browser and click F5 and the user remains in the system ignoring the logout in the other browser....
how do I solve this problem?
each browser uses its own cookies to check user status. then logging out of website in one browser doesn't affect your status in others.
so the only way left is to avoid logging in users from different browsers at the same time.
Only one concurrent login per user in Asp.net
http://teknohippy.net/2008/08/21/stopping-aspnet-concurrent-logins/

same session value exists among different users

I am developing and intranet web application. In Global.asax file's session_start event I get the domain identity using user.idenity and put it into session value. Now I have a master page where I am accession that session value to show the user name.
I am using windows authentication and identity impersonation true. But after publishing it the user name who first logins in the system gets displayed to everyone.
I am not able to find out the cause. Please suggest.
It's hard to determine the problem without some sample code, but I can guess what's happening.
Are you understanding that opening a new Web browser tab, or just opening the same URL in the same tab may start a new session?
Session state is persisted as a cookie in the client-side (Web browser) and any tab or window within the same browser session (that would end if you close and re-open the browser) shares it. In other words: all tabs or same browser session windows will share the same session state in the server-side.

How to ensure that Session ID does not expire when new browser window of same website is opened?

I have a ASP.NET website.
Here's what happens:
I open the site and log in.
I open another window of the same site in IE.
When I do that, it takes me to the page which is suppose to be shown when session expires.
So, can you please let me know how to ensure that Session ID does not expire when we open the site in another browser window?
Thanks!
The session is not expiring because you've opened a new window; the new window must not have the cookie used to store the session-id. Most of the time, these cookies are transient or "session" based cookies.
Session cookies may or may not be shared between browser windows, depending on the browser and how you open the new window. For ex., in IE 9, a new window launched using Javascript, Ctrl+N, or Ctrl+T will share session cookies. However, a new window launched by going to File / New Session will not share session cookies.
You also wont see cookies shared between different browsers (for ex., IE and Firefox).
To add a somewhat more simple answer to Michael's excellent response - the short answer thus is "You can't directly achieve this".
But what you CAN do is implement tracking within your application so that you are always aware of what a user's last action was, and no matter what session they come in on, forcibly keep them in your designated workflow.
To achieve that, however, you have to basically ignore session variables (which may be a good idea anyway ;)) and the like and implement a framework that constantly tracks a users behavior, current location and any other related information. There's obviously a lot of overhead involved but that's the only way I know of to ensure that a certain user will always end up where you desire them to end up when they log in from different browsers, machines, etc.

ASP.NET Session State Security Problem

I have a website in which people's 'logged in' state is confirmed by their session cookie (and a value within the session which they get after they log in). The cookie is set to httpOnly & require SSL.
Let's say somebody has 2 Firefox windows open, window (A) has my application and they are logged in, and window (B) has something else open.
If they close window (A) without explicitly logging out, then open a new window (C) and access a logged-in-only resource from my web application, it will still load because the cookie is still there and they are authenticated. The timeout on my sessions is already very low, but I need to stop this attack possibility because people may access their data on a public computer.
How can I prevent this from happening?
Don't know about other browsers, but Firefox keeps the same session id among all browser windows. You should close ALL windows of Firefox to generate a new session id. So in your example close window A and B, then open C and you should be redirected to login page or something.
You could go for a simple approach of destroying the cookie on the window.close event.
Most browsers have this functionality in that all windows can share the same session cookie for the same site. There is no way I know of server side to stop a browser from doing this.
If you absolutely need to stop this from happening then I can only suggest storing an additional value in the pages themselves or the querystring and also confirming this value within your session.
This could prove to be quite an overhaul of your security though.

Categories