-
Notifications
You must be signed in to change notification settings - Fork 25.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is the Authorize attribute needed in Razor Pages? What about Roles, Claims and Policies? #6301
Comments
@Ponant The There's a line in the Filters for RP topic at that top that explains ...
I looked to see if there was an issue open discussing supporting a scenario where filters could be applied to individual page handler methods, but I don't see one. You can ask the engineers to see if it's in their long-range planning by opening an issue in the MVC repo: https://github.com/aspnet/Mvc/issues. If you do, please cc/ me on it, so I can see what they say. |
Thanks @guardrex but I still do not fully grasp the framework. What would be the better alternative to transcribe |
You should be able to put that on a page model class. It will apply the policy to ALL handlers for that page.
Yes, that's right. There's an overload that will allow you to specify a policy ... Tell you what ... I'm going to add an example of that to the topic. Right now, there's just this one line there ...
It's a good idea to add a quick example in the text. I'll use this issue to track the work, and I'll get to it within a couple of weeks (we're crazy busy at the moment with 2.1 work).
AFAIK, yes. That should work. If it doesn't work, ping me back, and I'll take a closer look (it's been a while since I've played with putting a policy on the |
@guardrex , ok I will try it out but my question was to be able to go through my code as I am porting things to Razor Pages. In the meantime, yes I think I think the docs could be updated, examples are much better than a sentence :) . I think you could see with @blowdart if there is no need for an update on |
It does sound like there's a doc update needed, either a page for traditional MVC and one for Razor Pages, or mix them into one (which might confuse people) |
@blowdart , I learned pretty much all I needed from your single Workshop 2.0, but it was all traditional MVC. The equivalent for RazorPages would just perfect for many people I think. I looked up if you talked about razor pages and security, but nothing so far. |
For me that's kind of on purpose for a couple of reasons,
|
I'll take a look when I get to this, but the updates for this issue will be for the RP auth topic. When I see where more work is needed (e.g., Security TOC area), then I'll open one or more new issues for that. That work will probably fall to another author. I should be able to look at this in a few weeks. Sorry for the delay, but I'm slammed at the moment. |
I totally agree with your points @blowdart , at the same time it seems that Razor Pages will be cleaner in the long run. As a side note, let me say that this AddDefaultIdentity really sucks (sorry for the team). Here in Europe GDPR is ruling and you cannot just take an identity library without knowing what is inside. And it is pretty much likely you will have to override it. Scafolding did not help much. And AddIdentity seems an outsider. |
Yea, GDPR is painful, we're balancing ease of use, with helping you meet your obligations. 2.1 will see enhancements, around cookies and download/delete, see https://blogs.msdn.microsoft.com/webdev/2018/03/04/asp-net-core-2-1-0-preview1-gdpr-enhancements/ Now I've not seen any legal advice saying you can't take something without knowing what's inside per se, just that you need to be aware of what your database contains, which I suppose is the same thing. If documentation on the default fields helps open a new docs issue and I'll get on it. |
Yes I have seen already 2.1 and I am working on it to port an app from 1.0 that we have been building. That is great that you did this, really. Now, GDPR I know quite a bit about it because I have to, and I can see that I agree with a lot of their requirements. Also, I will bet a beer that you will have a similar thing in the US (see the Facebook discussion a few weeks ago at Congress etc). Regarding you last paragraph and as far as I can see, my understanding of GDPR and for reading the Azure docs on the matter is that GDPR will be a shared responsibility. So I see two reasons why I think it is better to offer a VS experience project template that reveals most of the code from the outset (as it used to be). The first reason is that, in my opinion, 80 devs out of 100 will likely make changes, even minor but they will have to scaffold, so make life easier for them and they can pack to a lib if they want latter. The second reason is that GDPR is not only about what the db contains, but also how you protect the data. The prime example relevant for this discussion is how you set password policies, how set set sign in. Here the practice is to confirm email prior to entering the website. Another practice that will boom in the future is following the NIST recommendation and anyone who does some math would agree with the, the idea of upper case letters+some non alphanumeric one to create pwds is just ridiculous. It is in general better to set long paraphrases. I assume these things can be changed but my point is that it is less direct with this default UI stuff. |
There's another balancing act here. GDPR is more than just code, as I know you're aware. But most developers aren't. We can't and won't say "This makes your site GDPR compliant", because that's utterly false. You have to make decisions specifically for your own use case. Which I can't do automatically. But this is a conversation that should happen down a pub. With an expensed bar bill :) |
Of course you cannot say this, but the picture is that you kind of offer a car whereas they (will) need the spare parts as far as they want to have a public or corporate facing website. Trump will pay for the beer! |
@Rick-Anderson thanks, I remember having seen the old traditional MVC example, so this will help. |
This may be a really dumb question. But I am a recent web developer (many years of desktop and back end). In developing a real application, how do you best handle a site where you will be setting up users ahead of time? For instance, a client wants a portion of their site to be a internal web portal, without using Azure AD login. They just want to create and manage logins themselves so that they can also have some of their customers access it without having to create AD accounts for them. Do you just custom write pages to handle all of this or is there a template or other way to speed that up. Also, if you wanted to just assign them a password ahead of time, you obviously cannot just punch that into the database -- would you modify the code using the "register" as a template and go from there? Thank you for the help getting me going. Joe |
@joeruder We recommend ASP.NET Core Identity. It's fully featured and well supported by our documentation and sample apps. The docs kick off the coverage with Introduction to Identity. WRT to your specific questions ... 'Yes' on the template. You'll see that there is app template identity configuration built-in to the RE: Assigned passwords ... Any approach or configuration that has significant risk isn't recommended or supported by MS. Every practice pertaining to password management that's supported and recommended is covered by the docs. AFAIK none of the supported password management strategies allow the assignment of passwords; however, I'll defer to the security experts here ... and none other than THE @blowdart 🎯 is listening! |
Yes you'd use register as a template, no we wouldn't really recommend it, if only because we don't have password expiration, so you can't force a change on first login |
@joeruder Use ASP.NET Core Identity like @guardrex mentions. To manually create the users: adapt code from the Registration page. For passwords: Create the users with random passwords. Adapt code from the Account/ForgotPassword page to send users an email with a token in the url that when clicked will take them to the Account/Manage/SetPassword page. |
Fixes #6301 [Internal Review Topic](https://review.docs.microsoft.com/en-us/aspnet/core/security/authorization/razor-pages-authorization?view=aspnetcore-2.1&branch=pr-en-us-11246) * Sample to 2.2 * Lean out sample (remove *wwwroot* and references to static assets) * Drop the cookie policy bits (but leave the HTTPS given that this is an authz samp) * Add examples of method policy overloads + a link to the policies topic * Topic UE pass * XREF links
I am pretty much confused as to how Authorization/Authentication would now work in Razor Pages. What if you want to set the equivalent of MVC [Authorize(Policy = "AtLeast21")] in Razor Pages? It seems to me that the docs about Claims, Role-based policies semantics dot not exactly apply in Razor Pages anymore, is that correct? Thanks!
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
The text was updated successfully, but these errors were encountered: