etc
How do you want the feeback? It seems you accept PR only for the dev branch.
You can either just write your feedback here - or click the "edit on github" button on the doc page.
I finished reworking QS 6-8, and the combined sample.
I'm wondering about https://github.com/IdentityServer/IdentityServer4/pull/2856/files#diff-71f9631bfa2ca3c38575e79f74c3924fR146 and the IETF Best Practice recommendation to not to use implicit flow and move to PKCE even for web clients that if there should be a note a clear note about it? If I didn't read the diff wrong, AllowedGrantTypes = GrantTypes.Implicit was changed to AllowedGrantTypes = GrantTypes.Code.
As for context: https://medium.com/oauth-2/why-you-should-stop-using-the-oauth-implicit-grant-2436ced1c926, for further links to IETF and other explanation.
I'll add https://brockallen.com/2019/01/03/the-state-of-the-implicit-flow-in-oauth2/ as it explains this well.
@leastprivilege , I need to know what your priorities are.
I went through the first tutorial 1 ClientCredentials and followed it step by step on a windows machine using Visual Studio 2019 preview executing every command that is written and copy pasting the Client Program.cs as it is not present in the rst doc file (you provide a link, though). I can make it run properly but only if I modify the configuration csproj files. In that sense the documentation is somewhat lax.
The main modifications are:
-main async in the client program file needs C# 7.1 which can work if you add <LangVersion>latest</LangVersion>
, as is the case in your template
-the default scaffolding of the dotnet new of the Api gives "applicationUrl": "http://localhost:5001;http://localhost:5000", which will crash since port 5000 is for IS.
-SSL runs by default in my case, so I need to modify the http string in Client.
All in all the tutorial is lax but it can be fixed by the reader if he goes through the fixing of the above. Do you want to leave it as is or would you prefer to be more careful by including the above?
Also, why not going all SSL in the tuto as this comes as a default and is gradually enforced virtually everywhere?
Let me know
OK - thats good feedback. It would be great if you add the additional steps.
wrt HTTPS - I don't care too much. It's all localhost.
Done
I understand the conclusion in 8_aspnet_identity.rst but, still, it would have been nice to have a tuto that allows one to have a configuration similar to what occurred in 2.0, a full IdentityServerAspNetIdentity with registration etc+ Mvc client + Api. Any insight on that?
Mainly because we're focused on IdentityServer, and not to write your entire identity management system for you.
So you are downgrading the service. I would not advise a half backed solution.
I'm sorry you're disappointed. That normally comes from a misalignment of expectations. Let me help you readjust those so you know what to and what not to expect from our free open source software offering.
The IdentityServer framework you or your company is using has hundreds (if not thousands) of person-hours in it that you or your company did not have to pay for. While feedback is appreciated, entitlement and insolence are not.
Perhaps it's not clear from our documentation, but it's expected that you're familiar with the protocols that this framework implements. It is not our responsibility to educate you with that understanding. It's similar to Microsoft's ASP.NET offering -- it's not their responsibility to educate you on how HTTP works. If you glean some further understanding from reading the samples, templates, or quickstarts, then consider it a bonus.
Similarly, as we do not provide the identity management system, and it is not our responsibility to educate you on how to do that properly (or implement it for you in samples, templates or quickstarts). Specifically for ASP.NET Identity, there are numerous templates, docs, blog posts, training materials, and other sources of information available (not to mention the source code itself).
If you or your company don't have such expertise and require assistance in any of these areas, then you can hire us for consulting. Or if sharing guidance on identity management with the community is so important to you or your company, then you can hire us to write ancillary documentation or whitepapers.
But without any collateral from your or your company, these sorts of complaints simply waste everyone's time. I hope this clarifies our relationship thus far so that you don't feel scorned.
Its a blue moon or what? @brockallen take it easy and stop being condescending. My last post was an advice, not a complaint. If you make a half backed solution then I take the right to advise you that this is a half backed solution that potentially will be viewed as a downgrade of the free service. If you are offended by that or if you put every github user in the same pot then it's better to shift your view on how open source works. Actually, I was implicitly proposing my help to do it for you, for free ;). But for that I needed to see if 1- you would be interested, 2- which Asp.Net Identity template will be the choice.
@leastprivilege , I went through the docs and all works fine except for a recurring issue so I am not sure on which repo the PR should be made:
In the tutos, e.g. 8_aspnet_identity.rst, the mvc client is set to AllowedGrantTypes = GrantTypes.Hybrid,
and the docs insists and prints out Config.cs that this is hybrid, as expected
but the template dotnet new is4aspid -n IdentityServerAspNetIdentity gives AllowedGrantTypes = GrantTypes.HybridAndClientCredentials, and I checked this was indeed the case here
https://github.com/IdentityServer/IdentityServer4.Templates/blob/dev/src/IdentityServer4AspNetIdentity/Config.cs
Other templates show this difference , too, so either the docs or the templates should be fixed. Let me know.
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.