由于C#添加了可选参数,因此使用可选参数或方法重载被认为是更好的做法,或者是否存在您希望使用其中一个的特定情况.即具有许多参数的函数更适合w /可选参数？
URLEncode转换字符如下:
- Spaces()转换为加号(+).
- 非字母数字字符转义为十六进制表示.
这与W3C类似,但不完全相同
应用程序/ x-WWW窗体-urlencoded
这是默认的内容类型.使用此内容类型提交的表单必须按如下方式编码:
控制名称和值将被转义.空格字符由'+'替换,然后保留字符按RFC1738第2.2节中的描述进行转义:非字母数字字符由'%HH'替换,百分号和两个十六进制数字表示字符的ASCII代码.换行符表示为"CR LF"对(即'%0D%0A').
控件名称/值按它们在文档中出现的顺序列出.名称通过'='与值分隔,名称/值对通过'&'彼此分隔.
我的问题是,是否有人完成了确定URLEncode是否生成有效的x-www-form-urlencoded数据的工作？
由于我们的应用程序的性质,我们可以让用户通过大量的auth提供程序进入,其中一些使用OAuth 1.0(特别是LTI).每当我们不识别登录然后不得不处理复杂的身份合并时,我们不想总是创建一个新的用户帐户,我们希望邀请显然是新用户通过OpenID识别自己(Google和Microsoft主要是因为这涵盖了我们的大多数用户.)我们可以问他们他们的U/P,除了我们不做U/P - 我们总是倾向于只支持通过第三方身份提供商登录,并且真的不想改变它.
因此情况将是我们的自定义身份验证方案(LTI/OAuth1.0)收到第三方声明,确定这些声明对我们的系统是新的,然后将挑战转发给我们的默认身份验证方案.完成该方案后(成功的auth或用户拒绝(即NoResult))我们理想情况下将返回原始方案,以完成使用提供的声明创建新用户或向现有用户添加其他登录.完成所有这些操作后,将返回最终的AuthenticationTicket,并且请求将在进行身份验证后正常进行.
我可能会想到这一切都是错的,如果是这样的话,我很乐意接受更好的指导.但基本的业务要求是,我不希望在为传入的个人提供通过其他登录方法将自己标识为现有用户的机会之前创建新用户.
目标环境是ASP.NET Core 2.0或2.1.
使用[Authorize]属性可以轻松设置仅由特定用户或角色允许的操作.例如
[Authorize(Roles = "Administrator")]
public ActionResult Index()
{
...
但是,当我想要逆时,我遇到了一个问题.有没有办法使用MVC框架功能允许除名称或角色指定的所有经过身份验证的用户？
期望的用法类似于:
[DoNotAuthorize(Roles = "RestrictedUser")]
public ActionResult Index()
{
...