Develop Reference

AccountController in Microsoft Identity on Blazor change endpoints

I'm trying change endpoints, and default pagaes of Microsoft Identity autentication in Blazor Project with azureB2C authentication.
I got two endpoints:
MicrosoftIdentity/Account/SignIn
MicrosoftIdentity/Account/SignOut
I want to change this on for e.g. account/SignOut.
After sign out, browser redirect to MicrosoftIdentity/Account/SignedOut, I want to change this rule.
I was trying create my own AccountController.cs but it's not work. I don't know, how can I use my own AccountController in this case,because Microsoft docs, don't explain this.
I discovered that, when I create file SignedOut.cshtml in Area.MicrosoftIdentity.Pages.Account, I can change view of default pages. But I get error about conflict
"warning CS0436: The type 'Areas_MicrosoftIdentity_Pages_Account_SignedOut'...."
I don't know what should I do. Sorry for my English, I'm still learning.

How to delete a specific cookie on startup, using .net core 2?

I need to delete a specific cookie when my app starts, before heading to home page.
I had this inside a controller action method, with a redirect to home page, setting up my startup class to use as route template this controller and action method.
However, there must be a way I can set up a method to delete this cookie, and execute it from startup?

In ASP.NET, this would be done in the methods of global.asax (often in Session_Start(...)). Read more here and here.
In ASP.NET Core, the startup.cs class is where all configurations of services are defined, as well as pipeline requests are managed.
You need to make your own custom middleware for this. Middleware is software that's assembled into an app pipeline to handle requests and responses.
There is another SO question on this topic here (with an answer):
ASP .NET Core webapi set cookie in middleware
For more in-depth cookie management look at this article:
https://www.seeleycoder.com/blog/cookie-management-asp-net-core/
More on middleware:
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/middleware/write?view=aspnetcore-2.2

C# Web API - Security for some of the GET requests

On an existing host I've added Web API Models & Controllers. I've added the following four:
Products
Orders
Categories
Users
When someone accesses the localhost:port\api\products, it returns all the products in JSON format.
The Create, Update and Delete statements are completely disabled, so we are only able to use GET-requests on the API (so either \api\products for a list of all products or api\products\# for a single products with id #).
Because the other CRUD's aren't used, there isn't a lot of security that should be added to the Web API, except for one thing: The Users
These will also return emails and such, which would be better to keep private and unreadable without the proper authorization (without entire log-in pages, but a way to authenticate yourself when accessing the Web API in for example Android HttpGetRequests).
So, the question: How should I add authorization for only the UsersController accessed by the Web API.
And, how can I encrypt the JSON in C# and decrypt it in Android again. If this second part is too big to answer I'll make a new question later on, my main focus is the low-end [<- without log-in pages, so built in into the GET-request] authorization of the Web API's GET-request for Users.
Edit 1: I did found this link where a new project is made with Authorization Changed to Individual Users. I also see that the user is registered and then logged in with POST and GET requests.
The following questions came into mind when reading through this link:
How to change the Web API's Authorization to Individual Users on an existing project?
Our authorization is done through OAuth (mainly Google-account) with our work e-mail address. I guess it's not possible / easy to authorize in the same way as in the link with a Google-account on Web API GET-requests.
Edit 2: After using the first link provided by Vladimir Gondarev I've added the [Authorize] to both the Get methods in the UsersController. In my project everything else was already used before, like a class that uses the AuthorizeAttribute, so just adding the [Authorize] was already enough for the first step. Now in the browser I get an unauthorized (JSON) back when I'm not logged in, which is good.
The next step would be to add the OAuth-authorization to the Android app, but that is an entire new problem / question that I will look into first before asking a new stackoverflow-question.

The simplest solution would be "Basic Authentification". In order to to implement it you have to derive from AuthorizeAttribute and then apply it to a method or a controller.
Here you find further info:
What is basic Authentification:
http://www.asp.net/web-api/overview/security/basic-authentication
Implementation:
ASP.net Web API RESTful web service + Basic authentication
You don't have to encrypt anything as long as you use HTTPS transport.

Using redirect from an HttpModule in an MVC web site, the "right" way

In the old days:
We used Response.Redirect, which sets the 302 response header and raises a ThreadAbortException to prevent anything else from happening after the redirect.
Now, with MVC:
We return a RedirectResult, which avoids the performance issues with ThreadAbortException and also allows the rest of the pipeline to inspect the results before actually sending them back to the browser. It's a different way of thinking about a redirect-- now instead of halting execution, a redirect is more like returning from a function.
My question has to do with mixing and matching these patterns.
Here's the requirement. We have an MVC site, and site contains an HttpModule that is in charge of authentication. If anything goes wrong with authentication, it drops cookies and redirects to an external web page. So the HttpModule makes a decision whether to send the redirect header or pass control to the MVC site. If it sends the redirect header, it has to halt execution-- if authentication failed, we don't want the site to be accessible in any way, shape, or form.
What's the "right" way to do this? Should the HttpModule simply use Response.Redirect just like we have always done? Or is there some clever way to accomplish this that is more consistent with the MVC pattern? Is there any way for the HttpModule to tell the pipeline to stop processing?
Or should I be using some completely different pattern, something that doesn't use an HttpModule? Perhaps an MVC filter? The thing is, the modularity/separation of concerns between the module and the site itself is very important. Anyone have any recommendations?

Thought I'd throw the answer up here in case anyone else has a question in a similar problem domain.
The answer is actually very simple.
HttpContext.ApplicationInstance.CompleteRequest()
The above call no longer throws a ThreadAbortException (this changed with .NET 2.0) so you can safely use it to tell the pipeline to halt execution. When the HttpModule exits, the web site proper is bypassed and control goes directly to EndRequest-- exactly what I needed. This was not possible in .NET 1.1 but I don't think there are a lot of 1.1 MVC projects out there ;)

Since you mentioned this was for authentication, you should use the Authorize Attribute. You can use it either at the Class level or the Action level.
[Authorize]
public class HomeController : Controller
{
// All actions will require authorization
}
public class ImageController : Controller
{
public ActionResult PublicImage()
{
}
[Authorize]
public ActionResult ImageRequiringAuth()
{
}
}
For your use case, you may need to inherit from the AuthorizationAttribute, as described in this answer.

ASP.NET MVC 2 "RequiresRole" attribute does not work

I'm developing a ASP.NET MVC 2 web application. So far, I managed to define access rules for every controller function, using "RequiresRole" attribute.
Suddenly, this way of defining access rules stopped working (now every user can invoke any of the controller methods). :S. I tried debugging, and it seems that user-roles are correct. I tried reviewing web.config, but did not find anything suspicious.
Don't know what else could be the problem.
Any ideas??

RequresRoleAttribute is intended for use on WCF domain data services, not MVC controllers. I believe the attribute you should use is AuthorizeAttribute, setting the Roles parameter.