What is the best place to know the CurrentCulture for each user logged in and do some setting per user based on that culture?
Can I use static constructor to assign static property!
Can I do something like this!!
public class MetricSystemHelper
{
private static bool _isMetric;
static MetricSystemHelper()
{
RegionInfo region = new RegionInfo(System.Threading.Thread.CurrentThread.CurrentCulture.Name);
if (true == region.IsMetric)
{
_isMetric = true;
}
else // USA, Liberia, Myanmar(Only these countries doesn't use metric)
{
_isMetric = false;
};
}
public static bool IsMetric
{
get
{
return _isMetric;
}
}
You could use the Thread.CurrentThread.CurrentCulture property to retrieve the culture info of the current ASP.NET user. If you need to persist this information you could store it in the database when the user logs in. But you should be aware that inside an ASP.NET application this property is populated from the <globalization> element in your web.config file.
So for example:
<globalization culture="auto" uiCulture="auto" />
auto are the default values. ASP.NET will then use the Accept-Language HTTP request header to populate this property. This property is usually sent by the client browser on each request. But be careful of the following gotcha: the same user could have 2 browsers (say Google Chrome and Mozilla Firefox) and he could have configured different culture settings in those browsers. So when he visits your website you could get different results for the same user.
If on the other hand you want to manage Language or Culture preference for the user in a browser agnostic way you should provide the user with the possibility to tell you his preference. For example this could be a setting in your website that the user could modify and you would store in the database.
Related
I wanna to check if the browser is IE and do something in razor page.
I just made a function in razor page to do that.
However, I think use the function to check if the browser is IE in every razor page is redundant. For independent user, I just need to check this only one time and set a global variable that IsIE=true/false . And other page will easily know that if it is IE.
The question is how can I get/set a global variable in razor page?
Thank you.
————————————————
To #Neville Nazerane ,here is the function which to check if is IE:
#{
Boolean IsIE = false;
string UA = Context.Request.Headers["User-Agent"].ToString();
if (UA.Contains("Trident") || UA.Contains("MSIE"))
{
IsIE = true;
}
else
{
IsIE = false; ;
}
if (IsIE == true)
{
}
else
{
}
}
HTTP requests work by clients sending a request (with header and body) to your server. Your server can then access this info and send a response. This doesn't create any persistent (ongoing) connection between the server and client. This means there is no permanent link between your server and each client. Any global variable you declare will be global for your server's web application and will be common for every client.
What you are trying to do here is create variables isolated from each client's connection. Normally this is done with the help of Session or Cookie variable. But in this case, I don't see how this will improve any performance over the code you have written. In your code, you are trying to access the Http Headers from the request. Cookies and session variables are also accessed in a very similar way. If anything fetching directly from headers must have a slightly better performance. If you are trying to clean up your code so you don't have to write this on every page, services could be quite helpful.
You can create a class for service something like this:
public class AgentChecker
{
public bool IsIE { get; set; }
// makes sure check is done only when object is created
public AgentChecker(IHttpContextAccessor accessor)
{
string UA = accessor.HttpContext.Request.Headers["User-Agent"].ToString();
if (UA.Contains("Trident") || UA.Contains("MSIE"))
{
IsIE = true;
}
else
{
IsIE = false;
}
}
// optional to simplify usage further.
public static implicit operator bool(AgentChecker checker) => checker.IsIE;
}
In your startup class add the following:
// to access http context in a service
services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>();
// makes sure object is created once per request
services.AddScoped<AgentChecker>();
Once this is set up, in your view you can use:
#inject AgentChecker checker
#* if you didn't create the implicit operator, you can use if (checker.IsIE) *#
#if (checker)
{
<div>Is ie</div>
}
else
{
<div>not ie</div>
}
The inject goes at the top of any view page you would like to use this in. While this still creates a new object each request, it is cleaner to use and only creates one object no matter how many partial views you are using.
The former HtmlHelper.AntiForgeryToken method which allows one to override the string path is deprecated.
[ObsoleteAttribute("This method is deprecated. Use the AntiForgeryToken() method instead. To specify a custom domain for the generated cookie, use the <httpCookies> configuration element. To specify custom data to be embedded within the token, use the static AntiForgeryConfig.AdditionalDataProvider property.",
true)]
public MvcHtmlString AntiForgeryToken(
string salt,
string domain,
string path
)
Tells you to use <httpCookies>. BUT httpCookies Element does not have a setting for PATH.
Is this an oversight in the deprecation of this method? What is the best way to overwrite this cookie path? (manually?) Running website in a virtual application is not implicitly adding the application path to the __RequestVeririfcation cookie.
Looking at the deprecation message:
"This method is deprecated. Use the AntiForgeryToken() method instead. To specify a custom domain for the generated cookie, use the configuration element. To specify custom data to be embedded within the token, use the static AntiForgeryConfig.AdditionalDataProvider property."
It tells us we can validate additional parameters whenever the forgery token is read back. So even if we can't set the path in the cookie, we can set the path as a property inside the token. To validate it later on, for example:
public class AdditionalDataProvider : IAntiForgeryAdditionalDataProvider
{
public string GetAdditionalData(HttpContextBase context)
{
return AdditionalData(context);
}
public bool ValidateAdditionalData(HttpContextBase context, string additionalData)
{
var currentData = AdditionalData(context);
return currentData == additionalData;
}
private static string AdditionalData(HttpContextBase context)
{
var path = context.Request.ApplicationPath;
return path;
}
}
When asp.net generates the token it will store the current path (or any other unique value you want to validate) for that app and
if you have another app running on a different path, when the token gets sent to that app (due to the lack of cookie path) it will validate the previous app properties against that app's properties. If it is a different set of properties it will fail and deny the request.
Additionally, looking at the code for the AntiforgeryConfig.cs, if the app is running in a virtual directory, it will add that virtual directory in the cookie's name by default:
private static string GetAntiForgeryCookieName()
{
return GetAntiForgeryCookieName(HttpRuntime.AppDomainAppVirtualPath);
}
// If the app path is provided, we're generating a cookie name rather than a field name, and the cookie names should
// be unique so that a development server cookie and an IIS cookie - both running on localhost - don't stomp on
// each other.
internal static string GetAntiForgeryCookieName(string appPath)
{
if (String.IsNullOrEmpty(appPath) || appPath == "/")
{
return AntiForgeryTokenFieldName;
}
else
{
return AntiForgeryTokenFieldName + "_" + HttpServerUtility.UrlTokenEncode(Encoding.UTF8.GetBytes(appPath));
}
}
So it will be like this:
_RequestVerificationToken vs
_RequestVerificationToken_L2RIdjAz0
Meaning App2 although can receive tokens from App1, it won't be able to read them since it will be looking always for App2 verification token only.
HTH
For ASP.NET Core - See: AntiforgeryOptions Class
Cookie - Determines the settings used to create the antiforgery
cookies.
Ex (adapted from Prevent Cross-Site Request Forgery (XSRF/CSRF) attacks in ASP.NET Core):
services.AddAntiforgery(options =>
{
options.Cookie.Path = "Path";
});
The best aproach to overwrite AntiForgeryToken's cookie configuration (Path, HttpOnly,...) is with encapsulation (Microsoft team post).
It is possible to configure the cookie path instead of setting it on the properties.
public static class AntiForgeryTokenExtensions
{
///<summary>
///Generates a hidden form field (anti-forgery token) that is
///validated when the form is submitted. Furthermore, this extension
///applies custom settings on the generated cookie.
///</summary>
///<returns>Generated form field (anti-forgery token).</returns>
public static MvcHtmlString AntiForgeryTokenExtension(this HtmlHelper html)
{
// Call base AntiForgeryToken and save its output to return later.
var output = html.AntiForgeryToken();
// Check that cookie exists
if(HttpContext.Current.Response.Cookies.AllKeys.Contains(AntiForgeryConfig.CookieName))
{
// Set cookie into the variable
var antiForgeryTokenCookie = HttpContext.Current.Response.Cookies.Get(AntiForgeryConfig.CookieName);
// Set cookie configuration
antiForgeryTokenCookie.Path = "/Path";
// antiForgeryTokenCookie.HttpOnly = true;
// ...
}
return output;
}
}
There is a last change that must be done and it is replace AntiForgeryToken() for AntiForgeryTokenExtension() if it is an existing project.
NOTES
With this code you can configure AntiForgeryToken cookie as a normal cookie.
It is also possible to add input parameters to this method, but I am not sure it would be a good practice.
There are different ways to get the cookies but I think that through Response.Cookies is the "most correct", since it is a response cookie.
IMPORTANT
It is needed to check if cookie exist first before trying to get it. If you try to get a Response cookie which doesn't exist, it will be generated. It doesn't happen with Request cookies.
COOKIE KNOWLEDGE
It is not the question itself but explains part of the code and it is quite important to know when we are working with cookies, so I consider it is good to have this information here too.
All Response.Cookies are in Request.Cookies, but not all Request.Cookies are in Response.Cookies.
If you create a Response.Cookie it will appear also in Request.Cookies.
If you create a Request.Cookie it will NOT appear in Response.Cookies.
If you try to get a non-existent cookie from Request.Cookies it will return a null.
If you try to get a non-existent cookie Response.Cookies it will return a new generated cookie.
SOURCES
There is the link where the developers tell to use encapsulation and many other things that could be useful.
Microsoft developers recommendations and information
Source to knowledge of cookies, Request.Cookies and Response.Cookies differences.
Difference between request cookies and response cookies
Difference between request cookies and response cookies 2
Check if cookie exist and difference between kind of cookies
I am new to application insights and have set it up using no custom events and I'm using all the defaults. The application is build on MVC 5. In the ApplicationInsights.config there's a comment saying:
"When implementing custom user tracking in your application, remove this telemetry initializer to ensure that the number of users is accurately reported to Application Insights."
We have a page where you are required to login so the default user logging isn't saying that much and we would much rather have the username being the unique identifier. Based on the comment it seems like this should be some kind of common modification and therefor easy to modify. When trying to google on "custom user tracking" I do not find anything interesting which seems a bit odd...
So how do I link the user in Application Insights to my username instead of going on some cookie which seems to be the default behaviour?
To link the user to your custom username, you can create the following telemetry initializer:
public class RealUserIDTelemetryInitializer:ITelemetryInitializer
{
public void Initialize(Microsoft.ApplicationInsights.Channel.ITelemetry telemetry)
{
// Replace this with your custom logic
if (DateTime.Now.Ticks % 2 > 0)
{
telemetry.Context.User.Id = "Ron Weasley";
}
else
{
telemetry.Context.User.Id = "Hermione Granger";
}
}
}
Then register this telemetry initializer in AI.config.
<TelemetryInitializers>
....
<Add Type="MyApp.RealUserIDTelemetryInitializer, MyApp" />
</TelemetryInitializers>
Controller
public partial class HomeController
{
private static String[] userPermissions;
public HomeController()
{
var MyPermission = Convert.ToString(TempData["MyPermission"]);
userPermissions = (MyPermission).Split(',');
}
[Microsoft.AspNet.Mvc.Facebook.FacebookAuthorize(userPermissions)]
public virtual ActionResult MyActionMethod()
{
return View();
}
}
Overload
Compilation Error
In the above block, we have following code
[Microsoft.AspNet.Mvc.Facebook.FacebookAuthorize(userPermissions)]
It is giving below compilation error...
Not sure if it helps but this is how I let users add additional permissions.
/// <summary>
/// Use this method when an action fails due to lack of priviligies. It will redirect user to facebook with provided permission request.
/// Refactor to handle list of request.
/// </summary>
/// <param name="permission"></param>
private static void AddAdditionalPermissions(string permission)
{
System.Diagnostics.Trace.TraceInformation(permission + " not authorized for user.");
string facebook_urlAuthorize_base = "https://graph.facebook.com/oauth/authorize";
string scope = permission; //see: https://developers.facebook.com/docs/authentication/permissions/ for extended permissions
string urlAuthorize = facebook_urlAuthorize_base;
urlAuthorize += "?client_id=" + AppId;
urlAuthorize += "&redirect_uri=" + "https://mydomainnamehere.nu/";
urlAuthorize += "&scope=" + scope;
//redirect the users browser to Facebook to ask the user to authorize our Facebook application
HttpContext.Current.Response.Redirect(urlAuthorize, true); //this cannot be done using WebRequest since facebook may need to show dialogs in the users browser
}
It is my understanding that you cannot dynamically assign anything to an attribute argument (as the error message backups up).
I do something with my Custom Membership Provider that I think you could adapt to meet your goal. I wanted a roles/rights setup defining user access to various parts of the system without needing to assign a bunch of individual rights to the users but still have very granular control of what each role can do. I followed the approach here (with some changes) to accomplish this.
The approach I would take if there is a need to do this on the fly in your scenario is define a constant Role to use in the FacebookAuthorize attribute for an ActionMethod and then in whatever is handling your permission checking pass (or have it look up) the array of permissions for each "role". This way the "role" you assign to the AuthorizeAttribute is a constant.
I'm using ASP.NET MVC and Forms Authentication on my application. Basically I use FormsAuthentication.SetAuthCookie to login and FormsAuthentication.SignOut to logout.
In the HttpContext.Current.User.Identity I have stored the user name but I need more info about the logged user. I don't want to store my entire User obj in the Session because it might be big and with much more infomation than I need.
Do you think it's a good idea to create like a class called LoggedUserInfo with only the attributes I need and then add it to the Session variable? Is this a good approach?
Or do you have better ideas?
I use this solution:
ASP.NET 2.0 Forms authentication - Keeping it customized yet simple
To summarize: I created my own IPrincipal implementation. It is stored in HttpContext.Current.Cache. If it is somehow lost, I have username from client side authorization cookie and can rebuild it. This solution doesn't rely on Session, which can be easily lost.
EDIT
If you want to use your principal in your controller and make it testable, you can do this:
private MyPrincipal _myPrincipal;
MyPrincipal MyPrincipal
{
get
{
if (_myPrincipal == null)
return (MyPrincipal)User;
return _myPrincipal;
}
set
{
_myPrincipal = value;
}
}
In your test, you will set object prepared for testing. Otherwise it will be taken from HttpContext. And now I started thinking, why do I use Ninject to do it?
Store it server side in the session.
Eg.
// Make this as light as possible and store only what you need
public class UserCedentials
{
public string Username { get; set; }
public string SomeOtherInfo { get; set; }
// etc...
}
Then when they sign in just do the following to save the users info:
// Should make typesafe accessors for your session objects but you will
// get the point from this example
Session["UserCredentials"] = new UserCredentials()
{ Username = "SomeUserName", SomeOtherInfo = "SomeMoreData" };
Then whenever you need it fetch it:
UserCredentials user = (UserCredentials)(Session["UserCredentials"]);
I have written a couple of question/answers regarding doing custom authorization in MVC:
How to implement authorization checks in ASP.NET MVC based on Session data?
How does the Authorize tag work? - Asp.net Mvc
I actually like to use a CustomPrincipal and CustomIdentity which I set in the logon action method like
if (!String.IsNullOrEmpty(username) && !String.IsNullOrEmpty(password) && _authService.IsValidLogin(username, password))
{
User objUser = _userService.GetUserByName(username);
if (objUser != null)
{
//** Construct the userdata string
string userData = objUser.RoleName + "|" + objUser.DistrictID + "|" + objUser.DistrictName + "|" + objUser.ID + "|" + objUser.DisplayName;
HttpCookie authCookie = FormsAuthentication.GetAuthCookie(username, rememberMe.GetValueOrDefault());
FormsAuthenticationTicket ticket = FormsAuthentication.Decrypt(authCookie.Value);
FormsAuthenticationTicket newTicket = new FormsAuthenticationTicket(ticket.Version, ticket.Name, ticket.IssueDate, ticket.Expiration, ticket.IsPersistent, userData);
authCookie.Value = FormsAuthentication.Encrypt(newTicket);
Response.Cookies.Add(authCookie);
return RedirectToAction("Index", "Absence");
}
else
{
return RedirectToAction("LogOn", "Account");
}
}
else
{
return RedirectToAction("LogOn", "Account");
}
Then in the custom principal you can have methods that access specific information you passed in to the constructor like
((CustomIdentity)((CustomPrincipal)HttpContext.Current.User).Identity).DisplayName;
where the DisplayName property is declared in the CustomIdentity class.
Well you will have to store these somewhere. Two main possible places though:
The server
You can either put them into Session. I suggest you do create a separate class that will hold only data that you actually need to avoid of wasting too much memory. Or you can also store into Cache that can end up in having many DB calls when there are huge amounts of concurrent users.
The client
In this case if you can limit the amount of data with a separate class, to that and use whatever way to serialize it and send it to the client. Either in a cookie or in URI (if length permits and cookies are disabled)...
Outcome of these thoughts:
the main thing here would be to create a separate class if you gain much memory resources this way. So that's the first thing you should do.