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

[JENKINS-49274] Run reverse-proxy filter after default filter #36

Merged
merged 1 commit into from Feb 7, 2018

Conversation

Projects
None yet
5 participants
@tadfisher
Copy link
Contributor

commented Feb 1, 2018

Running the default SecurityReam filter last overrides the Authentication set by reverse-proxy-auth. In a default install, AnonymousProcessingFilter somehow resets the SecurityContext authentication, even though we should have set a token in our filter.

Running our filter last ensures our token is set regardless of prior filter actions.

Added tests to verify the fix.

@tadfisher

This comment has been minimized.

Copy link
Contributor Author

commented Feb 1, 2018

@oleg-nenashev

This comment has been minimized.

Copy link
Member

commented Feb 1, 2018

It has been introduced in #28 by @kuisathaverat . Also CC @Wadeck

@oleg-nenashev oleg-nenashev requested a review from Wadeck Feb 1, 2018

@Wadeck

This comment has been minimized.

Copy link
Contributor

commented Feb 7, 2018

I'm looking at this one, the tests seem buggy on my machine, still investigating...

Ok using Maven it's ok, using IntelliJ directly, the authContext is null inside the DefaultReverseProxyAuthoritiesPopulator and the basicGetUserDetails throw an exception. Any idea @oleg-nenashev about such issues ?

The test basicAuthenticate did not pass before your modifications and passed after, perfect.

@Wadeck

Wadeck approved these changes Feb 7, 2018

Copy link
Contributor

left a comment

🐝

@kuisathaverat
Copy link
Contributor

left a comment

🐝

@oleg-nenashev WDYT about to update the Apache httpd configuration example to be updated on the wiki page, I was going crazy because the Authorization and I did not realize what happens until I debug it.

<VirtualHost *:80>
    ProxyPreserveHost On
    ProxyRequests     Off
    AllowEncodedSlashes NoDecode
    Timeout 5400
    ProxyTimeout 5400		
	
    <Proxy "*">
        Order deny,allow
        Allow from all
        Authtype Basic
        Authname "Password Required"
        AuthUserFile /usr/local/apache2/conf/passwd
        Require valid-user		
	RequestHeader unset "X-Forwarded-User"
	RequestHeader unset "X-Forwarded-Groups"
	RequestHeader unset "Authorization"
	RewriteEngine On		
	
	RequestHeader set "X-Forwarded-User" "%{RU}e"
	RequestHeader set "X-Forwarded-Groups" "%{RU}e|users"	

	RewriteCond %{LA-U:REMOTE_USER} (.+)
	RewriteRule .* - [E=RU:%1,NS]
    </Proxy>

    ProxyPass "/jenkins" "http://jenkins.example.com:8282/jenkins" nocanon
    ProxyPassReverse "/jenkins" "http://jenkins.example.com:8282/jenkins"
</virtualhost>

I created this repo for future use https://github.com/kuisathaverat/docker-reverse-proxy-auth-apache-http

@oleg-nenashev

This comment has been minimized.

Copy link
Member

commented Feb 7, 2018

@tadfisher

This comment has been minimized.

Copy link
Contributor Author

commented Feb 7, 2018

@Wadeck Strange, I ran these tests in IntelliJ myself. Perhaps something's up with your run configuration.

@oleg-nenashev oleg-nenashev merged commit 0f3dc2d into jenkinsci:master Feb 7, 2018

1 check passed

continuous-integration/jenkins/pr-merge This commit looks good
Details
@chancez

This comment has been minimized.

Copy link

commented Apr 9, 2018

I think this is breaking my agent's ability to authenticate because they're providing http basic auth creds and the headers, causing the headers to be used when the basic auth creds are what need to be used.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.