An open discussion list for topics related to the geteduroam service

[Paul Dekkers <paul.dekkers AT surf.nl>]

Hi,

Ah, so I think you're maybe running with Apache? Apache by default filters out the Authorization: header. I believe you can add

SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

To your VirtualHost to pass the header to PHP.

I'm using nginx myself, and the documentation assumes lighttpd, but I can imagine you try with your favorite webserver and stumble upon this.

Regards,
Paul

On 17/08/2022 21:25, Darren Boss (via geteduroam Mailing List) wrote:

> YT1PR01MB9435E1FD2417B47DD4FD88A4966A9 AT YT1PR01MB9435.CANPRD01.PROD.OUTLOOK.COM">
> Got the response body logged via mod_security:
> {
>     "error": "invalid_request",
>     "error_description": "Missing SERVER parameter HTTP_AUTHORIZATION"
> }
>
> This is the cause of the 400 error on the Debian vm.
>
> From: geteduroam-request AT lists.geant.org <geteduroam-request AT lists.geant.org> on behalf of Jørn Åne de Jong <geteduroam AT lists.geant.org>
> Sent: Wednesday, August 17, 2022 9:14 AM
> To: geteduroam AT lists.geant.org <geteduroam AT lists.geant.org>
> Subject: Re: Problem with certificates generated 
>  
> On 17/08/2022 14:54, Darren Boss (via geteduroam Mailing List) wrote:
> > I redeployed the portal on Debian 11.4 (Bullseye) but now I'm getting a error 400 on the call from the Android app to /api/eap-config/. I decided to log the Authorization header to a custom log and was able to decode it using a JWT decoder. Looks fine, sub claim is my email address (using email nameid from Azure AD). Including the decoded JWT in case it's something obvious:
> >
> > {
> >     "__t": "access_token",
> >     "iat": "1660739494",
> >     "sub": "Darren.Boss AT alliancecan.ca",
> >     "realm": "alliancecan.ca",
> >     "scope": "eap-metadata",
> >     "code_challenge_method": "S256",
> >     "code_challenge": "LQpjYE1ZjYAC6i9OwaU3OFYUBR9-rV-X0ohvYcXpLi4",
> >     "client_id": "app.eduroam.geteduroam",
> >     "redirect_uri": "app.eduroam.geteduroam:/",
> >     "exp": "1676637094"
> > }
> >
> > jwt.io is flagging the dates as invalid but they look right to me and the iat matches the date of the apache log entry.
> >       
> I think the dates are supposed to be ISO strings.  I'll fix that in a 
> future release, but it's not really a problem since we don't need 
> interoperability with other solutions.
>
> Error 400 means typically something wrong with the OAuth request.  Can 
> you find the answer body?  It should tell you what's wrong.
>
> --
> Jørn Åne de Jong
> geteduroam
>