We Keep Coding

Can't get Unity Firebase userID

I'm trying to save the user data to the firebase realtime database directly after the user has been created. But the problem is not the saving, but the UserID. I save also save the user ID that i get from CurrentUser. and then i check in the realtime database and saw that the ID that stored was from a last user who recently created. And i check it in the editor by getting the current user Email and it showed the last user Email not the current user who are creating at the moment. Can someone help me to get the current user ID and not the last user id.
You guys can see the image from the links.
What ID should be
The last user ID showing up instead You guys can see that the ID don't event match. I did try redo the project and looking at the videos that from firebase it self. I really have no ide what to do, i am stuck for 3 days now.
public void SaveNewUserInCode(string userId, string Name, string Email) {
var currentUser = FirebaseAuth.DefaultInstance.CurrentUser;
string userNameId;
if (currentUser != null)
{
userNameId = currentUser.Email;
user = new User(userId, Name, Email);
string Json = JsonUtility.ToJson(user);
reference.Child("Users").Child(currentUser.UserId).SetRawJsonValueAsync(Json);
Data.text = userNameId;
}
}

It would be helpful to see the code that invokes SaveNewUserInCode.
I see a few potential dangers with the code you've posted:
The first is that any call (other than Auth.SignOut) is asynchronous. If you're caching userId immediately after Auth.SignInWithEmailAndPasswordAsync, you'll likely have the previous user still in Auth.CurrentUser (until the related task completes). See my related post on all the ways to wait for a task in Unity if you think this is the issue.
The second, especially if Email is sometimes null, you may be automatically calling Auth.SignInAnonymouslyAsync every time your app starts (perhaps old logic, I usually start my prototypes with anonymous users and later on add real accounts when it's time to do some user testing). This will always overwrite your current user even if you were previously signed in anonymously. You should always check Auth.CurrentUser before calling any of the Auth.SignIn methods, but definitely make sure that you don't have a stray Auth.SignInAnonymouslyAsync laying around.
If the issue is threading, I believe the following logic will fix your problem:
var auth = FirebaseAuth.DefaultInstance;
auth.SignInWithEmailAndPasswordAsync(email, password).ContinueWithOnMainThread(task => {
// omitted : any error handling. Check task's state
var user = task.Result;
SaveNewUserInCode(user.UserId, user.DisplayName /* or however you get Name */, user.Email);
});

ASP .NET Core using InMemory Cache per user

I have a system where at some point, the user will be locked to a single page. In this situation his account his locked and he cannot be redirected to any other page and this is after authentication.
The verification is done using Page Filters accessing database. To improve performance I have used memory cache.
However, the result wasn't as expected because once the cache is used for a single user it will affect all the others.
As far as i know, you can separate caching using tag helpers per user but I have no idea if this is possible using code
public async Task<IActionResult> Iniciar(int paragemId, string paragem)
{
var registoId = Convert.ToInt32(User.GetRegistoId());
if (await _paragemService.IsParagemOnGoingAsync(registoId))
{
return new JsonResult(new { started = false, message = "Já existe uma paragem a decorrer..." });
}
else
{
await _paragemService.RegistarInicioParagemAsync(paragemId, paragem, registoId);
_registoService.UpdateParagem(new ProducaoRegisto(registoId)
{
IsParado = true
});
await _registoService.SaveChangesAsync();
_cache.Set(CustomCacheEntries.RecordIsParado, true, DateTimeOffset.Now.AddHours(8));
return new JsonResult(new { started = true, message = "Paragem Iniciada." });
}
}
here i only check first if the user account is blocked in the database first without checking cache first and then create the cache entry.
Every user will be locked because of this.
So my point is... Is there a way to achieve this like tag helpers?

The CacheTagHelper is different than cache in general. It works via the request and therefore can vary on things like headers or cookie values. Just using MemoryCache or IDistributedCache directly is low-level; you're just adding values for keys directly, so there's nothing here to "vary" on.
That said, you can compose your key using something like the authenticated user's id, which would then give each user a unique entry in the cache, i.e. something like:
var cacheKey = $"myawesomecachekey-{User.FindFirstValue(ClaimTypes.NameIdentifier)}";
Short of that, you should use session storage, which is automatically unique to the user, because it's per session.

There are several alternatives to the cache. For details please see this link that describes them in greater detail.
Session State
An alternative would be to store the value in session state. This way, the session of one user does not interfere with the ones of others.
However, there are some downsides of this approach. If the session state is kept in memory, you cannot run your application in a server farm because one server does not know of the others session memory. So you would need to save the session state in a cache (REDIS?) or a database.
In addition, as session memory is stored in the server users cannot change it and avoid the redirection that you try to implement. The downside is that this reduces the amount of users that your server can handle because the server needs to have a specific amount of memory per user.
Cookies
You can send a cookie to the client and check for this cookie when the next request arrives at your server. The downside of this approach is that the user can delete the cookie. If the only consequence of a missing cookie is a request to the database, this is neglectable.
You can use session cookies that are discarded by the server when the session expires.
General
Another hint is that you need to clear the state memory when a user signs out so that with the next sign in, the state is correctly set up for the new user.

ASP.Net MVC claims authorization and authentication

Please help me decide how to do the authorization for my project.
The project is written in ASP.Net MVC and is an intranet application that lets users log in via Active Directory.
Users can either be Junior Lecturer, Senior Lecturer, HOD or SuperUser. That's easy enough with roles but the situation is more complicated than that because those roles are based on whatever information you are looking at. For instance, a Junior Lecturer can only see information for students that he lectures etc.
As far as I understand it, that's where claims come in. I should assign modules or students to a user.
But the process if further complicated because there is no list of AD usernames and their students/modules in any single place.
I need to be able to check several databases to see if a user should be allowed to see the information.
Sometimes though, a user who has access to see certain information will not pass any of those checks. Because of that I will have to create a database with an AD username, their role and their subjects/students.
So my question is really regarding authorization. Is it possible for me to have that level of control on the claims and how would I assign them and check them?
If its not possible - how am i going to do this authorization?
Having an if statement at the start of every Action in every Controller feels wrong - but that's all my colleagues can come up with.

If you create a class that inherits from AuthorizeAttribute then you have the freedom to do whatever complicated authorization process you see fit. See my answer here on how to do so.
Here is some code I am using to query and cache AD roles:
private static Dictionary<Tuple<string, string>, bool> groupIdentityCache = new Dictionary<Tuple<string, string>, bool>();
..
public static bool UserHasRole(IIdentity identity, string groupShortName)
{
// (we rename our actual AD roles to shorter ones relevant to the site
// e.g. [MyAuthorizeAttribute(Roles = "Support,Admin")])
if (!AdLongGroupNames.ContainsKey(groupShortName.ToUpper())) return false;
string fullADGroupName = AdLongGroupNames[groupShortName.ToUpper()];
Tuple<string, string> key = new Tuple<string, string>(identity.Name.ToUpper(), groupShortName.ToUpper());
if (!groupIdentityCache.ContainsKey(key))
{
using (PrincipalContext principalContext = new PrincipalContext(ContextType.Domain, "DOMAINNAME"))
{
using (GroupPrincipal groupPrincipal = GroupPrincipal.FindByIdentity(principalContext, fullADGroupName))
{
using (UserPrincipal userPrincipal = UserPrincipal.FindByIdentity(principalContext, GetLogin(identity)))
{
groupIdentityCache[key] = userPrincipal.IsMemberOf(groupPrincipal);
}
}
}
}
return groupIdentityCache[key];
}
public static string GetLogin(IIdentity identity)
{
string[] parts = identity.Name.Split('\\');
if (parts.Count() < 2) return parts[0]; else return parts[1];
}
If you cache role memberships, you must also clear the cache on Session_Start for changes to take effect.
You can modify this solution to include roles from non-AD sources (such as a databases of class membership etc.) by adding to the groupIdentityCache dictionary. Modifying groupIdentityCache can also help when testing.

Having an 'if' statement is wrong, it will cost you long iteration and a huge misuse of memory.
Basically, you can control your authorization at every level almost using the authorize attribute.
However, you do need a well-built entity to do so, in order to not get lost withing all of the rules. It is very recommended that you will have a proper plan of your authorization scheme before committing this.
You can try to use switch statements instead, which will be a lot better in practice.
Please note:
Authorization Article that might help you understand.

Hiding user password field from being displayed using CreatedAtRoute

I'm building an ASP.NET Web API and I'm currently implementing very basic user accounts. I have a User model which consists of just Email and Password fields, and I have a UserController class with the following action:
// POST: api/Users
[ResponseType(typeof(User))]
public IHttpActionResult PostUser(User user)
{
if (!ModelState.IsValid)
{
return BadRequest(ModelState);
}
db.Users.Add(user);
db.SaveChanges();
return CreatedAtRoute("DefaultApi", new { id = user.Id }, user);
}
Everything works perfectly, except when I POST /api/Users I get the password field sent back in the response body:
{
"Id":2,
"Email":"dummy#test.com",
"Password":"$2a$12$jTACgOlm2eO/OYcV5wrDnO2dmsnbWVnsCRzX1WfQKGsY4sYvh16gm"
}
How do I go about making sure that sensitive fields such as user passwords never get output in a response? I'd prefer a method that does it on the model level so that I never accidentally forget to implement it in a controller.

One option would be to always use a Data Transfer Object (DTO) when communicating between a client and the server. The example given by this article from the Web Api team is very similar to your problem.
I would create a UserDTO which wouldn't contain any sensitive data that I wouldn't want to transfer between my clients and the server.
That is how most APIs work, take Facebook, for example, the User passed via this API call is not the User from their Domain, it is a representation of a User with just the needed information.
Using a DTO you could control exactly what gets transferred, lowering data size and preventing secure information from leaking.
UPDATE: If you go that road you'll probably want to use AutoMapper, it reduces the amount of Object to Object mapping you have to do considerably.

It's too much to just remove some values we need to create a separate model, better to clean the data before returning, say
db.SaveChanges();
user.Password = String.Empty;
user.anyproperty = null;
return CreatedAtRoute("DefaultApi", new { id = user.Id }, user);

John,
The CreatedAtRoute method is intended to return the URI of a newly created resource. For example, if you are creating a new product, you may see the return as api/products/1234. The method will also return the serialized object you provide as a third parameter. The method is not aware of the nature of the object you are returning therefore it does not recognize any of the fields as sensitive.
In your case, you may clear the password field from the user object or return a completely different object that does not include this field. You are not forced to return the same object you just created.
Best Regards,
Daniel

Set proxy user in a GenericPrincipal, while keeping the old identity, using MVC

I have a site where I allow some users to proxy in as an other user. When they do, they should see the entire site as if they where the user they proxy in as. I do this by changing the current user object
internal static void SetProxyUser(int userID)
{
HttpContext.Current.User = GetGenericPrincipal(userID);
}
This code works fine for me.
On the site, to proxy in, the user selects a value in a dropdown that I render in my _layout file as such, so that it appears on all pages.
#Html.Action("SetProxyUsers", "Home")
The SetProxyUsers view looks like this:
#using (#Html.BeginForm("SetProxyUsers", "Home")) {
#Html.DropDownList("ddlProxyUser", (SelectList)ViewBag.ProxyUsers_SelectList, new { onchange = "this.form.submit();" })
}
The controller actions for this looks like this
[HttpGet]
public ActionResult SetProxyUsers()
{
ViewBag.ProxyUsers_SelectList = GetAvailableProxyUsers(originalUserID);
return PartialView();
}
[HttpPost]
public ActionResult SetProxyUsers(FormCollection formCollection)
{
int id = int.Parse(formCollection["ddlProxyUser"]);
RolesHelper.SetProxyUser(id);
ViewBag.ProxyUsers_SelectList = GetAvailableProxyUsers(originalUserID);
return Redirect(Request.UrlReferrer.ToString());
}
All this works (except for the originalUserID variable, which I put in here to symbolize what I want done next.
My problem is that the values in the dropdown list are based on the logged in user. So, when I change user using the proxy, I also change the values in the proxy dropdown list (to either disappear if the "new" user isn't allowed to proxy, or to show the "new" user's list of available proxy users).
I need to have this selectlist stay unchanged. How do I go about storing the id of the original user? I could store it in a session variable, but I don't want to mess with potential time out issues, so that's a last resort.
Please help, and let me know if there is anything unclear with the question.
Update
I didn't realize that the HttpContext is set for each post. I haven't really worked with this kind of stuff before and for some reason assumed I was setting the values for the entire session (stupid, I know). However, I'm using windows authentication. How can I change the user on a more permanent basis (as long as the browser is open)? I assume I can't use FormAuthentication cookies since I'm using windows as my authentication mode, right?

Instead of faking the authentication, why not make it real? On a site that I work on we let admins impersonate other users by setting the authentication cookie for the user to be impersonated. Then the original user id is stored in session so if they ever log out from the impersonated users account, they are actually automatically logged back in to their original account.
Edit:
Here's a code sample of how I do impersonation:
[Authorize] //I use a custom authorize attribute; just make sure this is secured to only certain users.
public ActionResult Impersonate(string email) {
var user = YourMembershipProvider.GetUser(email);
if (user != null) {
//Store the currently logged in username in session so they can be logged back in if they log out from impersonating the user.
UserService.SetImpersonateCache(WebsiteUser.Email, user.Email);
FormsAuthentication.SetAuthCookie(user.Email, false);
}
return new RedirectResult("~/");
}
Simple as that! It's been working great. The only tricky piece is storing the session data (which certainly isn't required, it was just a nice feature to offer to my users so they wouldn't have to log back in as themselves all the time). The session key that I am using is:
string.Format("Impersonation.{0}", username)
Where username is the name of the user being impersonated (the value for that session key is the username of the original/admin user). This is important because then when the log out occurs I can say, "Hey, are there any impersonation keys for you? Because if so, I am going to log you in as that user stored in session. If not, I'll just log you out".
Here's an example of the LogOff method:
[Authorize]
public ActionResult LogOff() {
//Get from session the name of the original user that was logged in and started impersonating the current user.
var originalLoggedInUser = UserService.GetImpersonateCache(WebsiteUser.Email);
if (string.IsNullOrEmpty(originalLoggedInUser)) {
FormsAuthentication.SignOut();
} else {
FormsAuthentication.SetAuthCookie(originalLoggedInUser, false);
}
return RedirectToAction("Index", "Home");
}

I used the mvc example in the comments on this article http://www.codeproject.com/Articles/43724/ASP-NET-Forms-authentication-user-impersonation to
It uses FormsAuthentication.SetAuthCookie() to just change the current authorized cookie and also store the impersonated user identity in a cookie. This way it can easily re-authenticate you back to your original user.
I got it working very quickly. Use it to allow admin to login as anyone else.