Hi, I just migrated to version 2.0 and I realized the following:
The difference is only the ending slash.
check the discovery document - this has the correct paths...
I know, but can you not make it a little bit more flexible? ;) ... it was working before.
why?
It is not a big deal, I just got a few bug reports where the token request failed for some of my clients/users, even though I have documented it correctly.
So it seems that it would make life a little bit easier if it works like in version 1 ;)
Well, that's how the web works. I suspect the bugs you got were because humans inadvertently added a "/" to the URL.
I would say that most APIs don't care if a slash is added or not. E.g. it does not matter for ASP.NET Core MVC
If PathString doesn't think they're the same, I'm inclined to not add custom code to special case those URLs (especially when it seems this is due to human input):
agreed
Hi, i'm having the same issue.
What if we have the discovery endpoint disabled? How can the clients figure out that they are putting an extra slash in the endpoint?
//
// Summary:
// Gets or sets a value indicating whether the discovery document endpoint is enabled.
public bool EnableDiscoveryEndpoint { get; set; }
As this changes the previous versions contract, and this option must always be set to true, should it be removed?
Thanks and sorry for reviving this closed issue :)
To work around the issue, until all your clients are upgraded, you can use the following URL Rewrite to remove the trailing slash:
web.config:
<configuration>
<!-- other settings go here... -->
<rewrite>
<rules>
<rule name="IdentityServer4 - Remove trailing slash" stopProcessing="false">
<match url="(.*)/$" />
<conditions>
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
</conditions>
<action type="Rewrite" url="{R:1}" />
</rule>
</rules>
</rewrite>
</configuration>
This is so frustrating. You are not thinking on clients from legacy applications for example that would be hard to change and re-deploy just because you don't wanna add something that MVC Router already does for example.
After landing here, in case you don't wanna force web.configs on your app and are using another mechanism of hosting other than IIS, you can add the rule directly on the Startup.cs class:
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
app.Map("/identity", cfg => {
/*
* According to this issue: https://github.com/IdentityServer/IdentityServer4/issues/1676
* IdentityServer4 fails if the request contains a "/" in the end and unfortunatelly some
* of the requests on classic contains that and since the owner of the project refuses to
* fix it, we need to add a rewrite rule at the code level.
*/
var rewriteOptions = new RewriteOptions()
.AddRewrite("(.*)/$", "$1", true);
cfg.UseRewriter(rewriteOptions);
cfg.UseIdentityServer();
});
}
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.
Most helpful comment
This is so frustrating. You are not thinking on clients from legacy applications for example that would be hard to change and re-deploy just because you don't wanna add something that MVC Router already does for example.
After landing here, in case you don't wanna force web.configs on your app and are using another mechanism of hosting other than IIS, you can add the rule directly on the
Startup.csclass: