Is there a way to handle login and logout session of standalone vb.net application?
I have an application with a DB data. Users can access this data using application API's.
I already have login and logout functions defined for the users, but they have to login every time they open application, which is safe way, but in a local intranet environment its not necessary to do it every time.
I was wondering if i could store some kind of session id on a local PC where this application is running and then crosscheck if its still valid and not request users to fill in the login details.
But storing key to access the data is not secure. So how would i go about to make it secure and user friendly?
Is there a resource on how to handle the sessions?
My goal is:
1)Open app
2)Login to your account and access data
3)Do stuff ya need
4)Close app.
Few moments later..
Open app and you still logged in and can do stuff.
Few days later...
Open app and it asks to login.
Im thinking of doing something like this:
On login:
Check if session is expired
If expired = true
Set sessionID
Save sessionID in registry
Save UserID in registry
Set endOfLifeDate
Problem with this, someone could snoop the registry and get them sessionID and userID and get acces to the DATA.
Then next thought is:
On login:
Check if session is expired
If expired = true
Get CurrentNetworkPCname
Hash the userid and sessionID and CurrentNetworkPCname
Save sessionID in registry
Save UserID in registry
Set endOfLifeDate
this way you will need to be on the same pc to access the DATA.
Im open to ideas, im no expert as you can see.
I'm setting a session value in one app and it's not available in any other app once the redirect happens. It's available in the source app (the one where the value is set) though. Is this expected behavior?
I've inspected session IDs in the origin app and in the target redirected app and they are different. So how can/should I pass the session variables from one app to the next? I need this for setting the authenticated user and currently it doesn't work due to this behavior.
Kind regards
Seba
The problem was that I was using different session secrets for each app. When using the same session secret, it works as expected.
Seba
I have created a simple WebAPI in Visual Studio C# to act as my backend to Angular.
Users can register via the Angular frontend and passed to a controller in the WebAPI to register that user in the backend DB (MSSql). All fine.
I am using token authentication from Angular to my API and using claims and roles to verify the user is logged in and has access to the requested controller.
How, as an Admin, can I disable another user so they are instantly locked out?
An example would be: A rogue user starts abusing the Angular application and I need to lock them down instantly and not to wait until their token expires and they are required to login again.
I could do a check in each and every controller to lookup the user in the DB and check their status and if I have set their status to "locked-out" then return say a 403 forbidden status from the controller but this seems a lot to lookup the user for each DB request they make.
Is there a "dot-net" way of doing it? I would love to be able, as the admin, to instantiate the said user, change their claim value for "status" to "locked-out" and I simply check their claim when making api requests but I can't see a way of changing another users claims.
Any ideas?
Thank you.
Expanding on my comment above, we have a handler in our pipeline that handles Authorization. We do look at that Authorization header and parse it but all of the controllers rely on the already-parsed value that we hang in the Properties collection. That way all AuthZ/AuthN occurs in this handler and whatever the handler sets in the Properties collection is what all of the application sees.
In your case the handler would need to be able to check whatever throttle or lockout you are using and replace the actual claims received with your "user is locked out" claims instead.
I am creating a web application which will be used by App's Administrators and for security reasons we don't want to allow multiple active logins from a single user at any point of time.
I am storing session data in the web browser's cookie and want backend to have active user's information who are currently logged in to the application so that on successful login request I can find out if this particular user already has an active session. If that is possible then I can block the login for that user.
One way to do that is storing IsLoggedIn in the Database with LastLoginTime and on each login, I can use this two flags to identify if an active session exists.
Open to other better solutions if any
I think a more robust solution than checking last login times would be to generate and store an id for each new login and then include a middleware to make sure the session's id for each user matches what you expect. That way every time the user logs in on another device the previous one will be invalidated and only one session will be valid at a time. You may even just be able to use express-session's req.session.id.
Well, you type username and password in form, hit "OK" button. Then data going to server side and check users database if that user is existed. Then it return user id. And what next?
That data is saved in cookies?
Does it mean, that with every clicked link, site login you to website again?
I mean,
you click some link on site
browser redirect you to that page
site checks your cookies
site grab username and password from cookies
site checks is that data is valid (via connecting to database)
show page to you
Is that correct?
User enters credential.
System validates credential.
Upon successful authentication, server saves user object into session.
System grabs user info from session.
System displays webpage.
Tadaa!! :)
UPDATE
To add a little more...
User visits the secured webpage.
System checks if session contains a user object.
If user object exists in session, allow user through to visit the page.
If user object doesn't exists, redirect user to login page.
You don't need to store user password in the session. In fact, it is highly discouraged. Checking to make sure the user object exists in the session is sufficient.
When the user clicks the logout page, then proceed to invalidate the session... that's it. :)
Almost correct. You rarely go to the database with every request. You usually set a cookie with a expiry date and save the user session and info in memory. So every time a request is made, if the user is not authenticated, you authenticate him, generate and send him a cookie with, say, 5h expiry. So, in the next 5 hours, whenever a request comes in with that cookie, you trust that the user is an authenticated, valid user and you don't have to check the database.
It's not how every site does it nor it is the only way to manage session and cookies but I think it is the most widely used.
You should probably use sessions, but that's pretty much the gist of it. That way the data doesn't accidentally persist.
I mean, for my simple site at home, that's how I do it. But it's still locally hosted, so the security is guaranteed to be crap.
Oh, and no need to check with the database whenever you click on another link -- too much time wasted.
Typically, an application takes advantage of the session that is established between the browser and the web server, and makes a note that that session is "authenticated". "session" is a built in feature of HTTP. If the browser is closed, or after a certain period of time passes, the session is automatically closed. If the user does an explicit logout, the application marks the session as not-authenticated.