In a Corda Node is there a way to get the current RPC user logged in? As in which RPC user is actually making the request to the node.
In a flow, you can use:
stateMachine.context.origin.principal().name
This will return the name of the RPC user who started the flow as a string.
Related
I like to implement the functionality
where if two users are trying to login with the same credentials then the first user should log out as soon as the second user login.
consider user one is logged in with his credentials from one machine
and he/ another user is trying to log in from another machine
then the user one session should be removed as soon as user one logged in.
Ps:
I tried to implement that by saving the current session id in the user table and overriding the OnCreated method from the IAuthSession interface and then checking in that if the request sessionId is the same as the saved session Id if same then process the request else call the lout endpoint.
But It will be not good for performance and I am not sure if it is a good way to do that?
PS: I am using a JWT token.
Update :
I am able to clear the session by using ICacheClient to get the session and then remove a session from the server using IRequest.RemoveSession(sessionId), but is it not log out the specific user.
You can't invalidate a user authenticating with stateless authentication like JWT which has the signed authentication embedded in the Token which is valid until the JWT expiry.
i.e. you can't revoke a JWT Token after it's already been issued.
There is a JwtAuthProvider.ValidateToken filter you can use to execute custom logic to prevent a user from authenticating which you may be able to use however that would require that you manage a collection of Token info you want to prevent from authenticating before its Token expiry.
I'm working on a spring-mvc based java app at the moment.
One of the features of this app is that the user can change their email address to another email address.
When the user changes their email address, current state functionality is to log the user out in the same operation, which is achieved by returning
redirect:/j_spring_security_logout
from the controller method that updates the users email address.
New webapp functionality is to only support POST (not GET) for logout, which causes the current functionality of logging out the user on email address change to break.
What is the suggested way around this?
Can I:
a) Send a POST somehow from the server side to log the user out?
b) Logout the user server side somehow (invalidate their session, clear their cookies, and redirect them to the login page?)?
c) Should the user be being logged out on email address change in any case or is this a strange thing to do?
Any advice is more than appreciated.
When using Spring Security with a Servlet 3.0 (or higher) capable container it integrates with the HttpServletRequest.logout method. When calling this method it will trigger the registered Spring Security LogoutHandler. Afterwards you can redirect to the page you want.
#RequestMapping
public String yourMethod(HttpServletRequest request) {
// your logic here
request.logout(); // Logout to force a re-login
return "redirect:/login"; // redirect to page you want
}
I have a use case where I would like to share a realm with a user that has not yet registered with Realm Object Server. The registered user would share a realm with a non-registered user by entering their email address. When the unregistered user registers using the app, they will be granted permission to the realm the first user owns.
How do PermissionOffers work if the user id doesn't yet exist? If the user id is an email address, can the PermissionOffer just hang until a user with the email address is created? What is the suggested workflow for handling something like this?
Permission offers are not bound to user Id. Instead, when you create a permission offer, a random token is generated that the first user sends via any medium (e.g. email/imessage) to the second user. The second user then accepts the offer by consuming the token and receives permissions to the Realm.
I'm using IdentityServer v4 to handle authorisation for my ASP.NET application, using Resource Owner flow.
I've implemented the IdentityServer4.Core.Services.IProfileService interface which has two methods, GetProfileDataAsync and IsActiveAsync.
When making a request to the token endpoint, the GetProfileDataAsync gets called as expected. We use this method to issue our claims.
However the IsActiveAsync method does not get called. I'd like to implement this method to determine whether the user is active in our database. At what point is this method supposed to get called?
The comment in the IdentityServer source (see below) suggests it should get called during token issuance, but the method isn't called when requesting a token. I suspect I'm missing something. Any help would be appreciated.
// Summary:
// This method gets called whenever identity server needs to determine
// if the user is valid or active (e.g. if the user's account has been
// deactivated since they logged in). (e.g. during token issuance or
// validation).
Task IsActiveAsync(IsActiveContext context);
Right now IsActiveAsync does not get called for resource owner password requests. I guess the assumption was that you wouldn't successfully authenticate a user if the user is inactive.
These details are not yet decided on - if you have a strong opinion on how this should work - please open an issue on github. We will lock down the API in late August.
I'm working on a push architecture that needs to support applications which allow for multiple users. This means more than one user can log into the application with their credentials. The problem I'm running into is what if user A allows push notifications, then logs out, then user B logs in and starts getting user A's push notifications?
What are some best practices for handling this type of thing? One thought I had was you could remember the last user who logged in and only display push notifications to the "logged in" user. You would have to send some sort of user context in the message payload so it could be checked against the logged in user. However this feels a little funky.
Anyone else ran into this? It's seems like a really relevant problem, especially for tablets where families tend to share the device.
We're implementing this by Registering the device with APSN, getting the device token and sending this to our server through a ws.
On the server side the device token is only associated with the last logged in user.
New app
User A (first ever user) uses IPAD A
Register with APSN, get token
Send token to our servers through ws
Search for token in db, token is new, store it
assign token to USER A
Next user logs into app
Register with APSN, get token
Send token to our servers through ws
Search for token in db, token exists already
Remove connection to USER A
assign token to USER B
SEND Notification to device WITH USERNAME
if username is logged in show it - else dont
Still not perfect as its sent to home screen first so to ALL users
I think your suggestion is acceptable in a multi-user app. It is much simpler to implement this in the client side, than on the server side. The downside is extra bandwidth wasted to send an unneeded notification. But vast majority of the usage is probably single-user so this may not matter much.
The alternative is to track the logged on users on your server and their current reg_ids. This could be more complicated because A could be logged on on multiple devices, then logs out from device 1, and B logs onto device 1, etc. and your server has to track all of these. So probably another table to track the relationships between 'Logged On Users' to 'Reg Ids'.
If you hate the idea of sending unneeded notifications, go with the server route. If you value Keep-It-Simple principle, go with the client route.
Let's suppose users of your app can logging on multi devices.
We have to make two API on server side:
func setUserDeviceNotifyToken(userId: Int, deviceToken: String) {}
func removeUserDeviceNotifyToken(userId: Int, deviceToken: String {}
On your app side, you have to call setUserDeviceNotifyToken API on every Login In and call removeUserDeviceNotifyToken on every logout.
On server side, you can track every user with its deviceNotificationToken and send notification for correct device.
Notice: If your service doesn't suppose to support multi device login with one user, you can handle it just by one updateUserDeviceNotifyToken and pass null for remove user's device token.
Notice 2: Do not let user logout before calling removeUserDeviceNotifyToken API.