Skip to content
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

Prevent Override of [Authorize] #42

Open
KirschnerMatt opened this issue Mar 9, 2016 · 6 comments
Open

Prevent Override of [Authorize] #42

KirschnerMatt opened this issue Mar 9, 2016 · 6 comments

Comments

@KirschnerMatt
Copy link

I'm trying to use the .Net Cas Client alongside my custom Asp.Net Membership implementation. To do this, I would like to bind the client's Cas authorization to it's own Data Annotation, rather than have it simply override the default.

Is this possible?

@TheHokieCoder
Copy link
Contributor

@KirschnerMatt are you still experiencing this issue/have this need? I am trying to help work on the open issues for the project, so if you still want this answered I'll try to help look into it.

@KirschnerMatt
Copy link
Author

Nope, I wound up rolling my own custom Cas client using MVC filters.

@TheHokieCoder
Copy link
Contributor

@KirschnerMatt Thanks for the quick reply back. Glad to hear you worked out a solution.

@serac OK to close this (now) non-issue?

@serac
Copy link
Contributor

serac commented Apr 13, 2017

Actually I think this sounds like a useful feature. Let's leave open and consider how we might accomplish it, possibly in context of a framework refactoring.

@TheHokieCoder
Copy link
Contributor

Sounds good. I'll add it to my to-do list. Any feedback/suggestions from other contributors on how this might best be accomplished will be greatly appreciated.

@phantomtypist
Copy link
Contributor

We've done something similar with our applications however I'm not sure how easy it would be to do here and now. Let's say we introduced an action attribute called [CasAuthorize] that people could use, we'd have to come up with a way to not break people's existing code (i.e. they are already using [Authorize].)

Again, we'd need to take a look at the do-ability of this one without making too big of a breaking change for people, right?

Worst case we'd do it in a 2.x release to indicate major breaking change.

@scottt732 thoughts?

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

No branches or pull requests

5 participants
@serac @phantomtypist @KirschnerMatt @TheHokieCoder and others