I think I found a way (described below) to implement the following requested scenario, but I'll describe the complete context, in case I missed a simpler and/or cleaner solution to this issue.
The context
I have a multi-culture site that uses the following: ASP.NET MVC 5, EF 6.1, ASP.NET Identity 2.2, SimpleInjector. It is hosted on Amazon EC2 with sql server on Amazon RDS, while the urls are registered with www.register.it. I implement external OAuth login through FB, Linkedin, Google and Paypal payments.
I need to have multiple url (www.url-en.com, www.url-it.com etc) all pointing to the same site and then change language and _layout (masterpage) according to the url typed by the user.
The solution
Initially I thought about pointing all the urls to the ip of my site, but in this way I would need multiple ssl certificates configured (I don't even know if it's possible) and, more important, I wouldn't be able to manage callbacks from esternal login services and paypal payments.
So I configured redirection at the registrar level for each url to point to the main url (the english one), so I could read the HTTP_REFERRER variable in the global.asax Application_Start and set the culture cookie according to the referrer url.
I've an ActionMethod in the Home controller that set the culture cookie (the same used also by the language selector on the site's pages) and then I have a custom RazorViewEngine that picks the localized view (if present).
The issue is that, having the app_pool in integrated mode, I can't read Request object in Application_Start, so I tried to do it inside the OWIN Configuration method, but HttpContext.Current.Request.UrlReferrer is null. Should I get the referrer from the OWIN context? How could I do that?
It'd be better/simpler to do that in javascript checking whether url and referrer are different?
Thanks
Matteo
Why not detect the culture from the browser rather than using individual urls? Then based on the browser culture, you could tailor your urls to specific languages.
This would solve your multiple ssl issue, since you would only need one for the primary domain. It would also fix callback urls for payment gateways.
http://www.url.com/en-us/
http://www.url.com/es-es/
Related
Ok so I think I've settled on choosing BLAZOR for my upcoming project. But first I need to do something that is seemingly very basic.
For context, Blazor Server side will be how I interface with my SQL Server dB, I want "individual accounts" mode to be the way users authenticate. I'm using net 6.0,almost all tutorials out there seem to be net 5 since they all still have startup.cs files. Ok, but I also am creating a parallel app that is NOT a website, but I want it to grab data from the same database via routes after authenticating.
For example, website.com/api/data?variablestograb as a GET would send me some json data.
OK that being said, how do I login programmatically from an outside app? If you must know, the outside app is part of Unity C#. But that doesn't matter so much, what itll do is use a post call to login in via the api routes. Something like
Website.com/api/login?un=blah&pw=haha
This will generate a cookie and I can grab it with the session data and I'll use this with every get call hence.
Just using the basic templates, Blazor server net 6.0 with individual auth, how do I set up such a route? Looking at the files, I'm at a complete loss on how the login pages are actually passing data around.
Thanks!
Update: the specific ask is exactly how do I modify the Blazor Server Net 6 Individual Accounts template to allow me to authenticate a user via an external access api? My thought would be to reference the route above for /login/ but that might not even be the best practice. But even if it is, how exactly and where would I update the template to make this happen?
(I have a feeling it's pretty basic to do, but I've been reading tutorials for weeks now and they're all just talking about internal authentication and verification within each Blazor component. I basically want an external program to also be able to "drive the car" remotely, but first it must authenticate.)
If you're building an API for this from scratch, then it seems like you have the right idea, no matter what happens, you're going to send the cookie to be website every request or at least a session id which contains all the information provided. From a database perspective maybe create a session table which then contains all the info you want and also can be easily found. That's a way for you to create a cookie for client server communication, however this is from my limited knowledge and may not be the best way.
I'd recommend hiding information like keys in the header to prevent exposure, looking at other APIs like the Spotify API you can see they set the authorisation bearer.
Exposing all the information for the credentials in the URL for what could be sensitive database behaviour may not be the best. You can hide the information in the header for every request you make.
Maybe have a default controller that obtains the user information before handling any specific requests and making it accessible to your other methods/requests?
The basic process for any external authentication is:
Redirect to the external log in page.
External Provider does it business.
External provider posts to a page on your site with the authentication information included - normally security info in the header or a cookie.
The Blazor app reads the authentication information with the AuthenticationStateProvider.
Normally you just need to write a customer AuthenticationStateProvider and code to redirect if the user is not authorized. This may be a manual button in the top bar, a you aren't logged in page with a button to log in, or an automatic redirect to the provider. The return for the provider is either your landing page or some other page to tell them they logged in successfully.
The custom AuthenticationStateProvider replaces the standard one in DI services and provides the security information to the Authorization components.
Search for "blazor custom authentication provider" will get you lots of good resources.
I am currently supporting an existing ASP.NET MVC web-site that was written by another developer. Many parts of the site were upgraded to more modern frameworks, and I would like to redirect users to the new site where possible. However, there are still some pages that will have to continue to be used on the old site until I can finish the migration.
The server is Windows Server 2008, IIS 7.0, .NET 4.5
Let's say the old URL is: https://www.companysite.com/
The new site is in a virtual directory at: https://www.companysite.com/thenewsite/
What is the best way to selectively redirect users to the new site, where I have those parts built, but also leave the old site accessible for the pages that are not yet transferred to the new design?
For example, I would like to redirect:
https://www.companysite.com/contracts/ to https://www.companysite.com/thenewsite/contracts/
But I can't redirect every path globally. For example:
https://www.companysite.com/shipping/ can NOT redirect to the new site yet, as I haven't built /thenewsite/shipping/ yet.
Here are some ideas I had, but I could use some guidance as to which one would be best:
Add a Response.Redirect or a html meta refresh to specific pages in the old site (Lots of effort)
Use the URL Rewrite module, with a custom rule (not sure how to do this)
Hopefully this makes sense. Any help or suggestions would be greatly appreciated.
For IIS 7.0 you will probably want to use https://www.iis.net/downloads/microsoft/url-rewrite
There are others and it depends on version of IIS. I used to use Helicon Rewrite and as an ISAPI plugin is was at the front of the request pipeline and that's important for performance, you don't want a request to get to a Controller before it's wrong, you'd want to catch it at the Routing at latest.
Whichever URL rewrite tool you use the key is to make them return the correct HTTP code.
A 301 redirect is a permanent redirect. It is cacheable and any bookmarks for this URL should be updated to point to the new URL. A 302 redirect is a temporary redirect. A 303 redirect is the same as a 302 except that the follow-up request is now explicitly changed to a GET request and no confirmation is required
I am getting some special characters and some letters along with the url at runtime. The url is like
http://b1.elenageosystems.com/%28S%28z1qmpcpllhmuoxgsnkhcbflh%29%29/Default.aspx
Here you can see the special characters appended along with the url after b1.elenageosystems.com/.....
Default.aspx is my page
You can view my project - www.b1.elenageosystems.com
This is so-called Session ID that used by IIS to manage your sessions, it is added to every URL firing from the same browser session.
Many IIS-based frameworks (for example classical ASP.NET) depend heavily on sessions and require this ID to overcome generale stateless nature of HTTP requests, this is why IIS provides (and implements) fully transparent support for it.
If you don't like these URLs, you can also use Cookies to store your Session ID. You can configure the way how you store your IDs for sessions either per WebApplication using your web.config file in your application or globally for your complete IIS server.
You find more how to change these settings on MSDN.
I have a Web application which uses authorization via different social network account (i.e.Instagram). I created my account in Instagram, registered my Website URI (i.e. MyApplication.com) and stored secret tokens in .config file.
Every time user logs in I use these tokens. Everything works fine until user visited www.MyApplication.com.
According to Instagram developers API page www.MyApplication.com and MyApplication.com are different sites. Do I have to register WWW version of my site?
This requires to use another token pair. Thus, I have to check user authorization request twice!!! But it's not a normal solution.
Any ideas to do that much clear?
www.MyApplication.com and MyApplication.com are different.
More or less the www. is just a convention.
It's a subdomain just like app.MyApplication.com, images.Myapplication.com ect.
You wouldn't register both of them. Instead you would set up on your sever to either redirect www.MyApplication.com to MyApplication.com, or the other way around, and redirect MyApplication.com to www.MyApplication.com.
This way you only have to deal with one of them. In your case it sounds like you'd just want to redirect everything with www. to just the regular domain name.
If you're interested in the debates between www. or not.
http://no-www.org/
http://www.yes-www.org/
There is an easy way to handle this your web.config. Mads Kristensen has it covered pretty well here.
http://madskristensen.net/post/url-rewrite-and-the-www-subdomain
How do I redirect url based on register client in c# .net or asp.net 4.0. For example if client registers as "client1" and our website is www.mycompany.com for every page client proceeds should get www.client1.mycompany.com.
More detailed example:
For example another client created is Client2. The pages i have created in general is like
"www.mycompany.com/product.aspx"
"www.mycompany.com/categories.aspx" should be shown as
"www.client2.mycompany.com/product.aspx" and
"www.client2.mycompany.com/categories.aspx" respectively
I have searched on web and found for static pages or using Gloabal.asax during startup of application but haven't found any thing after user logged in.
I have done something similar before in a few sites and there are a couple methods you could use. Assuming that you have a url setup so that all subdomains ( *.url.com) will send any user to your server and you have IIS setup to handle them all (i.e. no host header required, just IP) in the same site you can use one of the following methods:
After login simply send the user to that url. Since .Net won’t care the url the server knows how to render it, then it should be that simple. This assumes all your navigation uses relative paths and you must enable cookie sharing for that domain. This is required if the cookie for login was give on 1.url.com and you send them to 2.url.com You can share cookies in the same domain, requires a little work, but can be done.
Create a generic login page that does a web service request back to the server to see if the user can login. If he or she can have it send back to the browser a command, along with the correct url, that tell the clients browser to post directly to that sites login page (send username, password). This will login them into their site and assign the cookies correctly all from one simple login page. You could even make an external login page that only exists for this purpose. In the end all the generic page did was see if they could login and the sent their credentials to the correct page that did the login. I recommend this be done in a post with ssl for security reasons.
I hope that makes since.
There's a project called UrlRewritingNet which I use - it's pretty old but the source is available so you could recompile it for 4.0.
Link is at http://urlrewriting.net/149/en/home.html