Skip to content
This repository has been archived by the owner on Dec 13, 2018. It is now read-only.

Returning 403 does not redirect to AccessDeniedPath #499

Closed
MaximBalaganskiy opened this issue Sep 29, 2015 · 11 comments
Closed

Returning 403 does not redirect to AccessDeniedPath #499

MaximBalaganskiy opened this issue Sep 29, 2015 · 11 comments
Assignees
Labels

Comments

@MaximBalaganskiy
Copy link

Returning new HttpStatusCodeResult(StatusCodes.Status403Forbidden) from an action does not redirect to a "forbidden" url. I am using cookie authentication in beta7.

@Eilon
Copy link
Member

Eilon commented Oct 1, 2015

@HaoK can you log a bug in MVC to create a forbidden result that sends a forbid response + 403?

@Eilon Eilon added the wontfix label Oct 1, 2015
@HaoK
Copy link
Member

HaoK commented Oct 1, 2015

aspnet/Mvc#3242

@HaoK HaoK closed this as completed Oct 1, 2015
@herecydev
Copy link

Is this still an issue for RC1 @HaoK ?

Given the following middleware configuration:

app.UseCookieAuthentication(options =>
{
    options.AutomaticAuthenticate = true;
    options.AutomaticChallenge = true;
});
app.UseOpenIdConnectAuthentication(options =>
{
    options.Authority = Configuration.Get<string>("AzureAd:Authority");
    options.ClientId = Configuration.Get<string>("AzureAd:ClientId");
    options.AutomaticAuthenticate = true;
    options.AutomaticChallenge = true;
    options.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
});

//MVC

When the MVC returns a 403 this is "caught" and made into a 302 redirect to the login page (causing endless redirects). My assumption was it would use the default AccessDeniedPath but it seems to ignore it.

@Eilon
Copy link
Member

Eilon commented Apr 28, 2016

@Tratcher any idea on this?

@Tratcher
Copy link
Member

@herecydev
Copy link

herecydev commented Apr 29, 2016

I've made the most simple gist I could to demonstrate this.

Given an end user that does not have the claim there, I'm seeing endless redirects.

@Tratcher
Copy link
Member

Oh, MVC isn't setting a 403 anywhere in your gist. It's failing to authorize which triggers another login flow. I think you're hitting this issue: #667

@herecydev
Copy link

Ah okay, perhaps I made some assumptions about this, so sorry about that. How exactly does the Authorize attribute work if it doesn't return a 403?

@Tratcher
Copy link
Member

It invokes HttpContext.Authentication.Challenge. For authenticated but not authorized Cookies or Bearer this can produce a 403, but for most of the other auth middleware this causes an infinite loop.

@herecydev
Copy link

Thanks, I'll keep tabs on the related issue. Hoping this will go into RC2!

@Tratcher
Copy link
Member

No, it's scheduled for post RC2. We're out of time for RC2 features.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

5 participants