Our application is using Symfony 2.0 and MongoDB with FOSUserBundle for user management.
Client wants to prevent login with the same username from different device at the same time in their application.
Our idea is to invalidate/delete all other sessions for the same user when the successful login occurs.
The problem is, that we cannot save session in DB, because Mongo Session handler was added later in the version 2.1.
The only solution we come up with is to iterate over the session files saved in file-system and check if the username of the user is saved in that file. If that is true, we just delete the file and login session on other locations are terminated. Of course we have to check that we don't delete the current session also.
Does anyone have a better idea how the problem could be solved?
If not, are there any hidden traps that we should know about?
You could add an IP address column to the user entity that stores the current user's IP upon login. On each page load (via an event listener), you could check the IP stored in the DB against the IP of the person requesting the page. If the IP in the DB doesn't match the current user's IP (someone logged in from another location), log them out.
To take it a step further, via ajax, you could make a call to the server every X seconds that performs the same type of check, and do a redirect to log the user out if the ajax request returns a bad match.
Related
We have user data which is present in a single mongoDB. Multiple applications are using this database for user authentication.
The current method for the authentication is when the user signs in any application for the first time, data is fetched from parentDB and saved it respective local application db. The flaw with this method is when the user gets altered in parentDB, local copy needs to be synced.
Another method that we tried was writing the model definition in all the applications and connecting to parentDB of which the flaw is changing the model definition in all the applications if their is any change
What would be the suggested method for maintaining such user management ?
I would move authentication to separate server connected to parent db, and make all user management also request authentication server. Can also proxy authentication from app server to authentication server, so from outside it still looks like each app has its own auth.
I've a problem with WebSphere Commerce and HttpSession. If I close browser page and then I re-open it I continue to the last session, until now no problem. When I do the first logon I send my user data to a program to trace my action but if I close and I re-open browser page the trace program "lost" session and the system not send my data to the trace program because I'm already logged.
How I can know when the browser page is open with a exist session?
I tried with a HttpSessionListener implementing the methods sessionCreated and sessionDestroyed but sessionCreated method is call only when I logon.
Any idea? I thinking to use a Listener or a Filter.
Thanks to all!
Thanks #Ranjith V for response.
I mean, I login in WCS then when I land in browser page there is a JS that know if I just logged and then it send my user data (user.123456.en) to a external system. This system trace my actions. When I close the browser I lost session with external system but in WCS my session continue. When I open a random page in WCS, as Home page or After sales, I already logged and JS not understand that must send my user data to external system. I need insert a variable in session if I open page and continue a exist session. The problem is here, how I know that this is a new browser session?
There is a java class that check if I'm logged and continue a session? If there is I extend it and insert my variable here and at last JS know if it must send data.
I hope I'm making myself clear.
Thanks!
I didn't quite get what you are trying to ask and what you mean by trace program. But you can use cookies to identify the session
How I can know when the browser page is open with a existing session?
WCS handles session using cookies. If you look at the request cookies, you know whether the user is authenticated or not. Look at the below article for more details on session handling
https://www.ibm.com/support/knowledgecenter/en/SSZLC2_7.0.0/com.ibm.commerce.admin.doc/concepts/csesmsession_mgmt.htm
I think you would need to use one of the below cookies
WC_SESSION_ESTABLISHED or WC_AUTHENTICATION_ID
I'm trying to secure a Cloud function in my Parse app. This function doesn't create objects or anything. It just calls an external API and returns the result. However, to make it secure I'm trying to create an anonymous user using the iOS SDK like so:
PFUser.enableAutomaticUser()
print(PFUser.currentUser())
which outputs
Optional(<PFUser: 0x7fd3535570c0, objectId: new, localId: (null)> {})
So seems like the user is being created. But when I make a request using the PFCloud object, my parse function in Cloud gets a null user:
PFCloud.callFunctionInBackground("<endpoint>", withParameters:[<params_dict>], block: {(result) -> Void in
print(result)
})
Result on console log says "user":null. Does anyone know what I could be missing? Also, is this the best way to ensure requests are coming from my iOS client only, and not from some other source?
Thanks.
Your anonymous user is null because unless you save that user or an object related to it, it will not exist on the server. From Parse documentation:
Anonymous users can also be automatically created for you without
requiring a network request, so that you can begin working with your
user immediately when your application starts. When you enable
automatic anonymous user creation at application startup, [PFUser
currentUser] will never be nil. The user will automatically be created
in the cloud the first time the user or any object with a relation to
the user is saved. Until that point, the user's object ID will be nil.
Also you cannot simply check if a request is coming from an iOS client. The whole point of a REST system is that server does not keep any state, it just responds to the requests from different sources. The sources have to send in their credentials (usually in a from of a security token which is issued by the server during a login) with every request. Server verifies the token is genuine and has not been tampered with before serving the request. Parse provides you with user authentication which makes it easy for you to verify that a logged in user is requesting something. You can then build extra security measures on top of that to make sure only certain users are allowed to access certain data.
I have user login feature in my application. I used Scala Play Framework as controller. I create sessions using withSession('userId'->userIDValue) for different users. My application has a feature that there will be one super user and super user can delete user. Now what happens is that if super user deletes a user but that user is logged in then that user's session is running till cookie of browser expires. Play Framework is stateless; is there any way to solve this problem?
On incoming requests, I think you need to verify that a user is still active on the Play side, and not just only trust the session.
If that's an expensive operation, e.g., you have to make a database call to verify if a user is still active, then maybe you can use the Play Cache API. If you only have one Play server instance, then it should be pretty easy -- you can just set something in the cache when the super user deletes a user, and have the cache item expiration be longer than your cookie expiration. If you have multiple Play server instances, then it's tricker. :)
Short version:
If the function wwv_flow_custom_auth_std.is_session_valid (or apex_custom_auth_std.is_session_valid) returns TRUE, is it possible that the session is expired but still alive? If so, how can you check if a session is expired?
Long version:
I have created a single-sign-on system for our Oracle APEX applications, roughly based on this tutorial:
http://www.oracle.com/technology/oramag/oracle/09-may/o39security.html
The only difference is that my master SSO login is in Perl, rather than another APEX app. It sets an SSO cookie, and the app can check if it's valid with a database procedure.
I have noticed that when I arrive in the morning, the whole system doesn't work. I reload a page from the APEX app, it then sends me to the SSO page because the session was expired, I logon, and get redirected back to my original APEX app page. This usually works except first thing in the morning. It seems the APEX session is expired. In that case it seems to find the session, but then refuse to use it, and sends me back to the login page.
I've tried my best to trace the problem. The "wwv_flow_custom_auth_std.is_session_valid" function returns true, so I'm assuming the session is valid. But nothing works until I remove the APEX session cookie. Then I can log back in easily.
Anybody knows if there is another call that would tell me if the session is expired or not?
Thanks
You can set the Maximum Session length in seconds under the application security attributes page.
Apex states the following:
"The session duration may be superseded by the operation of the job that runs every eight hours which deletes sessions older than 12 hours."
You could use the view apex_040100.APEX_WORKSPACE_SESSIONS to determine if a session is valid based on its existance or creation time. eg: session_created - systdate > 12Hours.
You should also use the "On session timeout direct to this URL" attribute.
This solution would require privileged access but you can query the wwv_flow_sessions$ view in your apex schema for any session that matches your username. If none exists, your session has timed out. This view also gives you a field 'idle_timeout_on' that will tell when your session is scheduled to time out.