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

Adds "challenge" property to BasicAuthenticationEntryPoint #177

Closed
wants to merge 2 commits into from

Conversation

dsyer
Copy link
Member

@dsyer dsyer commented Mar 4, 2015

This provides useful additional flexibility if you want a
WWW-Authenticate header but don't want the "Basic" challenge
(e.g. to prevent a browser from popping up a dialog).

See https://jira.spring.io/browse/SEC-2803

Dave Syer added 2 commits March 4, 2015 16:05
This provides useful additional flexibility if you want a
WWW-Authenticate header but don't want the "Basic" challenge
(e.g. to prevent a browser from popping up a dialog).

See SEC-2803
User can now set any header value he wants, and optionally only the
realm name in the default case.

See SEC-2803
@dsyer
Copy link
Member Author

dsyer commented Mar 4, 2015

That second commit is just an idea (the general version with a replacement for the realm in the deafult case). If you don't like it please just discard.

@rwinch
Copy link
Member

rwinch commented Mar 11, 2015

@dsyer Thanks for the PR!

I wonder if it makes more sense to put this in another AuthenticationEntryPoint all together. The reason is that BasicAuthenticationEntryPoint seems to imply that it is performing basic authentication. As soon as the challenge is removed, this is no longer the case.

What are your thoughts on creating an HttpStatusAuthenticationEntryPoint that allows setting the HttpStatus and (optionally) any headers the client wishes to send? I'm guessing in most cases a client doesn't even need the headers, so perhaps we should leave that out for now.

Thoughts?

NOTE I can make the changes assuming it meets your need

@dsyer
Copy link
Member Author

dsyer commented Mar 11, 2015

I'm ok with it either way. Thanks.

@rwinch
Copy link
Member

rwinch commented Mar 11, 2015

Closing this in favor of e776a1f

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

Successfully merging this pull request may close these issues.

2 participants