In a bid to try and make my Parse powered app more secure I would like to be able to expire sessions on the server side. Upon launching my App (or visiting the Web App) I will run a check to see if the Session Token is valid.
Where I am struggling is actually being able to monitor the activity of a session. Parse.com have alluded to this capability, however it is impossible to find anything mentioned in their documentation on the subject.
Additionally moving to NodeChef has given me the option to 'Expire In Active Sessions' However, it is not mentioned anywhere how it actually functions or how you can interact with this through cloud or client side code.
I do have the option of setting the session expiry time, however this is a hard and fast rule - it will happily expire the session even if the user is active! Not a nice user experience.
Does anyone have any ideas how I can manage this?
I used this solution:
Create cron job (in Linux) or Schedule Task (in windows) with Parse Code Function that will delete your expired token (With your costume logic)
Related
I have set up a OIDC on my nifi standalone instance, it works great and all but if i idle for more than 5 mintues it redirects me to an Unauthorized window message and says
"Unknown user with identity anonymous".
Refreshing solves this, however, is there a way to make sure to extend the connection, or a workaround to avoid these disconnects?
In case anyone is struck with a similar problem,
my solution is to overwrite the NAR file responsible to OIDCAuthentication (just increasing the expiration timer hehe)
its not a pleasant solution but it will do for the time being, until nifi supports refresh tokens or adds a feature to customize session duration.
stay updated at
https://issues.apache.org/jira/browse/NIFI-4890
It depends on used Identity Provider (IdP) - it generates token with preconfigured time validity. Usually, it can be configured on the client configuration level, but it is recommended to have short time validity. OIDC offers option how to renew access token, but it depends on used flow. It can be refreshed via refresh tokens (grant code flow) or silent refresh (implicit flow). It is not clear which IdP and flow is used in your case, so you can get only these general recommendation.
It's a requirement of the site I am building that users may only be logged in with a single session at a time. Should a user attempt to log in to the site from a different browser or machine while currently logged in, their login attempt needs to be rejected.
I've considered flagging the user object in the database as being logged in but this seems brittle to me as, if the user doesn't actually formally log out then the flag persists and the user gets unfairly rejected. To manage this I have to run some sort of cleanup task at regular intervals to ensure that those flags get reset, and this can introduce all sorts of other issues.
I'm using Sinatra as a core framework and Warden as an authentication manager. Is there a 'best practice' strategy for this sort of requirement?
this really is not an authentication issue, but a "how do I handle what happens when an authenticated user tries to login when they are already logged in" -- so you need to answer that question first. What do you want to do when someone is already logged in? Give the newest session priority? That is, kick the older session by the same user off?
Should a user attempt to log in to the site from a different browser or machine while currently logged in, their login attempt needs to be rejected.
and
if the user doesn't actually formally log out then the flag persists and the user gets unfairly rejected
are in direct conflict with each other. You have to choose which wins, the old or the new, and you've chosen the old… so there's nothing unfair there.
If you run a clean up then you're expiring their session, so you have to pick a time that works. This is an timeless problem for HTTP as it's a stateless protocol.
you could use a pseudo "forgot password" feature, where they can get an email sent to them that allows them to kick off the current user.
perhaps you could use websockets, which would allow you monitor the connection and kill the session if it dies at the other end. If it's still open though, you have the same choice as before.
I am developing a social network in ASP.NET MVC 3. Every user has must have the ability to see connected people.
What is the best way to do this?
I added a flag in the table Contact in my database, and I set it to true when the user logs in and set it to false when he logs out.
But the problem with this solution is when the user closes the browser without logging out, he will still remain connected.
The only way to truly know that a user is currently connected is to maintain some sort of connection between the user and the server. Two options immediately come to mind:
Use javascript to periodically call your server using ajax. You would have a special endpoint on your server that would be used to update a "last connected time" status, and you would have a second endpoint for users to poll to see who is online.
Use a websocket to maintain a persistent connection with your server
Option 1 should be fairly easy to implement. The main thing to keep in mind that this will increase the amount of requests coming into your server, and you will have to plan accordingly in order handle the traffic this could generate. You will have some control over the amount of load on your server by configuring how often javascript timer calls back to your server.
Option 2 could be a little more involved if you did this without library support. Of course there are libraries out there such as SignalR that make this really easy to do. This also has an impact on the performance of your site since each user will be maintaining a persistent connection. The advantage with this approach is that it reduces the need for polling like option 1 does. If you use this approach it would also be very easy to push a message to user A that user B has gone offline.
I guess I should also mention a really easy 3rd option as well. If you feel like your site is pretty interactive, you could just track the last time they made a request to your site. This of course may not give you enough accuracy to determine whether a user is "connected".
I'm just wondering how one could set this up without the BOSH dying. I have the sid, rid, and everything but I was wondering how long i could automatically log people on for the time of lets say a cookie and how is this achieved.
Your answer depends on how long it takes for your BOSH session to timeout. It's usually 60 seconds until it throws away the session.
Just a note- you probably do not want to automatically log in a user, since the proper XMPP flow is not done. Here's a typical flow:
-> Login and establish a BOSH session.
-> Send Presence
---> Server sends a <presence/> packet to all entities in your roster, notifying them that you are available.
---> Server sends a presence probe to all of the entities in your roster's server, getting their current availability.
<- Presence packets come raining down on your session.
-> Request roster items
<- Server sends you a list of items in your roster.
With the approach of using the same session, you skip all of this initialization, which I assume is important to your application, as you will not get presence of any entities until they change their presence. Sending another <presence/> stanza will not send you the current presence of everyone in your roster. So... if that isn't important to you, go ahead and do it. I'm just providing some useful information before you go and implement the thing and find out that there are caveats to your solution.
What worked for us was to use localStorage, and automatically log them in via a "Save my password" button. That makes it simpler and less work. Also, it can be confusing when a user reloads the page and they get logged back in automatically, versus a user closing the page and coming back in 5 minutes to be greeted by the login page. It's just plain confusing.
Good luck!
You can do one of the following as per your need and convenience:
Auto detect about user login status via cookies. Do an http-pre-bind and issue new rid/sid to the user. This will generally be transparent to user on your page.
Instead of issuing new "sid" on every page refresh/reload which can be quite expensive under high traffic, you can pool the underlying xmpp tcp streams. Next time when a user need sid/rid to start again, these can be fetched from the connection manager pooling the sessions.
I have an application that uses coldfusion's session management (instead of the J2EE) session management.
We have one client, who has recently switched their company's traffic to us to come viaa proxy server in their network.
So, to our Coldfusion server, it appears that all traffic is coming from this one IP Address, for all of the accounts of this one company..
Of the session variables, Part 1 is kept in a cflock, and Part 2 is kept in editable session variables. I may be misundestanding, but we have done it this way as we modify some values as needed throughout the application's usage.
We are now running into an issue of this client having their session variables mixed up (?). We have one case where we set a timestamp.. and when it comes time to look it up, it's empty. From the looks of it this is happening because of another user on the same token.
My initial thoughts are to look into modifying our existing session management to somehow generate a unique cftoken/cfid, or to start using jsession_ID, if this solves the problem at all.
I have done some basic research on this issue and couldn't find anything similar, so I thought I'd ask here.
Thanks!
I've run into similar problems on and off for years.
JSession cookies seem to help (no hard data on that) but one solution that I've implemented repoeatedly is using no-cache and cache expiry headers on every page.
http://www.bpurcell.org/blog/index.cfm?entry=1075&mode=entry gives some specifics on how to implement this.
In extreme cases, we've been forced to pass the token and cfid in the links/forms, but that is a PITA to implement, so I'd try the cache expiry/prevention soluiton first.
As far as I know, there are no "cons" in using J2EE session variables, unless you really need session to be active after user closes the browser. I think you should try and see how application behaves with it and see if that saves you trouble of refactoring.
To be sure that you are using all other settings try this:
<cfdump var="#APPLICATION.GetApplicationSettings()#" label="Application settings" />
If you have sessionmanagement and client cookies turned on, everything is fine, so try j2ee session variables.