[ 
https://issues.apache.org/jira/browse/GEODE-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ben Moss updated GEODE-2212:
----------------------------
    Description: 
We encountered a bug with Geode that only reveals itself when routing requests 
through the a proxy that modifies HTTP headers to standardize them in title 
case format.

gfsh uses the security-username and security-password headers to pass 
authentication credentials to the locator, but what we saw is that when these 
go through our proxy and are turned into Security-Username / Security-Password, 
we can no longer authenticate.

This request emulates what gfsh executes when you run "list members" with an 
HTTP connection:

{code:none}
curl http://$LOCATOR_IP/gemfire/v1/members -H "security-username: admin" -H 
"security-password: admin"
{code}

This request emulates what gets sent when going through our proxy. This should 
be the same but will fail:

{code:none}
curl http://$LOCATOR_IP/gemfire/v1/members -H "Security-Username: admin" -H 
"Security-Password: admin"
{code}

We narrowed the bug down to [these 
lines|https://github.com/apache/geode/blob/bd229d7681376a11ba2e37747e48844ffe65584c/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/support/LoginHandlerInterceptor.java#L99-L111].
 The HTTP spec specifies that headers should treated as case-insensitive but it 
looks like GemFire is only capable of working with lower-case versions of these 
headers.

  was:
We encountered a bug with Geode that only reveals itself when routing requests 
through the a proxy that modifies HTTP headers to standardize them in title 
case format.

gfsh uses the security-username and security-password headers to pass 
authentication credentials to the locator, but what we saw is that when these 
go through our proxy and are turned into Security-Username / Security-Password, 
we can no longer authenticate.

This request emulates what gfsh executes when you run "list members" with an 
HTTP connection:

```
curl http://$LOCATOR_IP/gemfire/v1/members -H "security-username: admin" -H 
"security-password: admin"
```

This request emulates what gets sent when going through our proxy. This should 
be the same but will fail:

```
curl http://$LOCATOR_IP/gemfire/v1/members -H "Security-Username: admin" -H 
"Security-Password: admin"
```

We narrowed the bug down to these lines 
(https://github.com/apache/geode/blob/bd229d7681376a11ba2e37747e48844ffe65584c/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/support/LoginHandlerInterceptor.java#L99-L111).
 The HTTP spec specifies that headers should treated as case-insensitive but it 
looks like GemFire is only capable of working with lower-case versions of these 
headers.


> gfsh http authentication fails when routed through a proxy
> ----------------------------------------------------------
>
>                 Key: GEODE-2212
>                 URL: https://issues.apache.org/jira/browse/GEODE-2212
>             Project: Geode
>          Issue Type: Bug
>          Components: core, gfsh
>            Reporter: Ben Moss
>            Assignee: Mark Bretl
>
> We encountered a bug with Geode that only reveals itself when routing 
> requests through the a proxy that modifies HTTP headers to standardize them 
> in title case format.
> gfsh uses the security-username and security-password headers to pass 
> authentication credentials to the locator, but what we saw is that when these 
> go through our proxy and are turned into Security-Username / 
> Security-Password, we can no longer authenticate.
> This request emulates what gfsh executes when you run "list members" with an 
> HTTP connection:
> {code:none}
> curl http://$LOCATOR_IP/gemfire/v1/members -H "security-username: admin" -H 
> "security-password: admin"
> {code}
> This request emulates what gets sent when going through our proxy. This 
> should be the same but will fail:
> {code:none}
> curl http://$LOCATOR_IP/gemfire/v1/members -H "Security-Username: admin" -H 
> "Security-Password: admin"
> {code}
> We narrowed the bug down to [these 
> lines|https://github.com/apache/geode/blob/bd229d7681376a11ba2e37747e48844ffe65584c/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/support/LoginHandlerInterceptor.java#L99-L111].
>  The HTTP spec specifies that headers should treated as case-insensitive but 
> it looks like GemFire is only capable of working with lower-case versions of 
> these headers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to