I am using the Membership.GetUser(User.Identity.Name).Email method to try and get the current user email address but its timing out, I just have one line, on which I declare and assign the returned value of the method to a variable
Here is my one line of code string userEmail = Membership.GetUser(User.Identity.Name).Email;,
I have tried this code both with or without the username parameter. I also tried checking first if user is authenticated but once it gets to this line it times out, I have also tried doing it totally from a different method.
Note: Windows auth is used on the web app
Membership is from ASP.NET Membership, not Identity. You need to use:
var user = UserManager.FindById(User.Identity.GetUserId());
Then, you access the Email property off that user object.
UPDATE
I got thrown by your use of the [asp.net-identity] tag. However, the same over all point applies. Membership is from a completely different authentication system than Windows Auth. When using Windows Auth, your user information comes from AD, so you simply need to add a UserPrincipal extension if you need additional information. See my answer in this related question.
Related
I have an API method where the authentication server allows an automatic registration when the user does not exist yet on first login.
The auth server would make a call to:
PUT https://some-api/api/v1/auth/users
The handler of this method will check if the user already exists, and create it when the user does not based on email.
My question is whether there is something inherently wrong with not specifying the id in url upfront. The problem being that in fact, there is no userId yet when the user does not exist.
I know that the usual format would be:
PUT https://some-api/api/v1/auth/users/:userId
Obviously the client can check whether the user exists based on email upfront, create a POST request to create the user, or GET if the user already exists.
This introduces more network requests so I'd prefer to avoid this.
I noticed that there is some common solution to use 'email' as resource identifier.
This works for me. One remark is that I do not particularly like to use an email address in the url, but in my case it is okay as this url will only be visible within the cluster, and is not exposed to the outside network.
Is there any solutions to understand from my MVC application that user already signed in into Office365?
Currently I'm using the code below to authenticate to my MVC application:
var authContext = new AuthenticationContext("https://login.windows.net/MyTenantId");
var authResult = authContext.AcquireToken("https://MyTenantId/AppWebApi",
"ClientId", new Uri("redirect uri"));
By this code user is suggested to enter his credentials to sign in into Azure Active Directory. And it works fine, but it doesn't see that user already signed in to Office365 and work with Word, for example.
The code you wrote there does not work in a web application. It might work while you are hitting localhost, but as soon as you deploy your web app to an actual server it will not be able to pop out the dialog. Did you get that code form some sample? Could you point me to that? This is already the 2nd question containing the same error in 2 days, after 2 or 3 years of the library being available.
Back to your question.
How did the user sign in your application? If you would have used AAD to handle web sign on, like in this sample, you would know upfront (and the answer would be always 'yes', just for the fact that he/she'd need to in order to have access to your application).
If you are using a different sign on system, there are techniques for finding out if a user is signed in without showing any UX, but they are pretty advanced (requiring the use of a hidden frame and special request parameters) and before digging deeper in that I think it would be useful to know what your scenario requires. Do you need a token, or do you simply need to know if the user is already signed in in O365?
say I have a Meteor.method addCredits(user, amount), that add the specified amount of credits to the user account. Then what is stopping a potential hacker from just scanning the source code, find the method, and call it from the client console?
Making sure users only execute methods they are allowed to is done by checking this.userId within the method on the server. That id gets set when the user logs in and is available in all methods. If no user is logged in this.userId equals null inside a method.
Management of user account and associating the userId with a connection is handled by using the accounts system, such as using the packages 'accounts-base' and 'accounts-password'. The accounts system is documented here.
this.userId is documented here.
An example of how to restrict method execution is here.
Nothing is stopping a hacker from doing that. In the method, you must check that the user has done something that gives him the right to call the method.
Is there any way to retrieve a user's email address after authenticating with Yesod's OpenId implementation?
In my test app, the redirection and authentication occur correctly, and maybeAuthId gives me an id to the corresponding entry in my database. However, that identity is stored as a URL.
I can work with this, but it'd be nice to also get the actual email used to authenticate as other OpenId packages allow. Is this possible with Yesod's OpenId? Is there something I can do with authOpenIdExtended (unclear how to use it)?
Have a look at the GoogleEmail module. One thing you need to keep in mind is that you can't necessarily trust every OpenID provider out there. If you use the email address for anything important, a nefarious user could simply set up an OpenID provider that let's him/her claim whichever address he/she wishes.
After looking into this again, I found an answer:
First, we need to use authOpenIdExtended with the right parameters:
authPlugins _ = [authOpenIdExtended [("openid.ns.ax", "http://openid.net/srv/ax/1.0"),
("openid.ax.mode", "fetch_request"),
("openid.ax.type.email", "http://axschema.org/contact/email"),
("openid.ax.required", "email")
]]
I found these values from this page: https://developers.google.com/accounts/docs/OpenID and verified them to work with Google and Yahoo.
Then, to use our retrieved email address, we call "credsExtra creds" on the creds parameter passed to getAuthId. This gives us a list of tuples containing the response from the OpenId provider. When using the parameters above to authOpenIdExtended we find our email in the key/value tuples with the values "openid.ax.value.email" (for Yahoo) or "openid.ext1.value.email" (for Google). I was expecting Google to also use the "openid.ax.value.email" key, but close enough.
I hope this helps someone.
I'm calling the Advapi32.dll LsaEnumerateAccountRights function having a policy handle from LsaOpenPolicy and an account SID from LookupAccountName.
However, try as I might, I'm always getting back 0xC0000034 which after translation by LsaNtStatusToWinError gives me "The file referenced cannot be found."
Which isn't a whole lot of good. My code handles this and goes on to grant the account SID the SeServiceLogonRight using LsaAddAccountRights, so I know that the policy handle and the account SID are fine as that would bomb out if something was wrong with one of those.
The end result is that the account does have the right it needs so overall the code works.
However, I'm using this within an MSI custom action, the Install checks to see if the account has the right and if it doesn't (or it fails as above) it grants the right and remembers it has done it in the install state. If a rollback happens and it added the right it then removes it. We never remove in an uninstall as other applications may have been installed using the same domain account that the services we run use.
So the problem is when an MSI performs a rollback - it will always remove the right as it always thinks it has added it. So checking the rights using LsaEnumerateAccountRights is used for this - but I just can't get it to work.
Any idea - please note that I'm using c# with DllImport attribute to expose the Win32 functions, and I'm not the worlds best Win32 programmer having been Unix before C#!
I have been struggling with this, too, but have just cracked it...
Retrospectively, I now see there was a clue in the msdn documentation:
"The accounts returned by this function hold the specified privilege directly through the user account, not as part of membership to a group."
See: link text
Get the policy handle from LsaOpenPolicy() and an account SID from LookupAccountName() exactly as you said.
If the username you entered was the name of a group ("Users", "Administrators", etc) then LsaEnumerateAccountRights() works fine and enumerates all the rights for the group.
If you call it on a username whose rights derive solely from the groups of which it is a member, then it returns 0xc0000034 (= Windows error 2 - The system cannot find the "file" specified), meaning (we now realise) "cannot find any individually assigned additional rights". It seems that the Windows Error 2 translation is a catch-all for "what you were looking for has not been found".
Now...
If you have ntrights.exe, run it... for example:
ntrights +r SeNetworkLogonRight -u MyUserName
Then, LsaEnumerateAccountRights() works fine, returns without error and enumerates a single right, "SeNetworkLogonRight".
I have recently run up against this same problem. In my testing with this issue it appears that the LookupAccountName call returns a security principal rather than the full SID. The actual failure seems to be that the section within the SID where the user rights would be is either not there or shortened to only the logon right.
Performing a LookupAccountName call on the current logged in user and then trying to LsaEnumerateAccountRights against that SID results in only the user logon right. Even though clearly, there are many other rights attached. Trying to retrieve any other users, other than the logged on user, successfully returns a SID. However, that SID will not have any user rights in it.
I have tested this on no domain workgroup systems and member systems of domains both as admin and regular users. The LookupAccountName call when successful, always results a SID that does not contain the full set of user rights.
I can only assume that if a complete SID could be obtained from the Security Database, then the LookupAccountName would properly iterate the rights.
I too have the exact same problem. Somebody suggested I get the SID via WMI with this query:
SELECT * FROM Win32_Account WHERE domain = 'ntdomain' AND name = 'username'
I tried it, using ConvertStringSidToSid() to get the magic blob LsaEnumerateAccountRights() expects and... same error. "The system cannot find the file specified."
I meet the same problem, it is because you dont assign spefic privledge to the user, so the user priveldge is empty, if you add one to it, it wont fail.
Call the same function with a group you can see everything working correctly.