[DX] More details about cors and header authorization in readme

[arendjantetteroo]

After installing this bundle and running into cors issue like 2 other closed issues on your repo (which i missed), it might be nice to add a hint about the cors nelmio bundle in case you run code that uses the jwt but not on your own domain.

Another issue i had is that Apache removed the Authorization header instead of providing it to symfony, so the authorization didn't work. This can be solved by adding some modrewrite rules to the htaccess.
http://stackoverflow.com/questions/11990388/request-headers-bag-is-missing-authorization-header-in-symfony-2

A link to the gfreeau bundle : https://packagist.org/packages/gfreeau/get-jwt-bundle might be nice as well.

Are you interested in a PR to the readme about these issues, so others can more easily and faster use this bundle?

[slashfan]

Any contribution is welcome :)

I'm not against adding help about CORS in the documentation at all, I just thought it was more of a global Symfony2 topic. But I'll definitely add it since people ask for it.

About your Apache problem, does it mean the bundle doesn't work at all without those modrewrite rules ? Sorry I only tested it on nginx servers. Maybe you could add your workaround solution to the configuration section of the doc/index.md ?

About GfreeauGetJWTBundle, you're right there should be a link to it in the doc. Besides, gfreeau has contributed many times to the jwt bundle. As I think of it, it might be nice to have the GetJWTListener directly in the main bundle. What do you think @gfreeau ?

[arendjantetteroo]

For someone new to the api and cors topic, it would be nice to get a helping hand when setting it up :-) I learned a lot about this the last week.

I used it on the php internal webserver locally, so only found the problem when pushing to production that runs apache. It worked there only when using the query method, but not with the authorization header. That's also why i looked at getJWT, because the form login failed for me. Probably because of the same apache problem, but i haven't debugged that fully yet. I'll make a PR for the documentation this weekend.

Integration the Getjwt listener into this bundle sounds like a great plan 👍

[gfreeau]

@slashfan I think it is better to stay separate. Some people may still wish to use basic auth or form_login listeners to obtain the token.

In addition some people may have some other method to provide the json web token to the user. For example they may provide the token with a long expiration time to be used in some script as hard-coded parameter.

It's better to keep LexikJWTAuthenticationBundle lean and just provide better documentation on the options available such as different listeners and CORS etc.

[slashfan]

@arendjantetteroo I'll add the doc about CORS this weekend :) I'll also try to test the bundle on an Apache server to see if I can reproduce the bug.

@gfreeau As you wish, but I didn't mean as a complete replacement for form_login, just as an extra option. By the way, It would be nice to add documentation about how to make it work with basic auth login because I don't think there is a success_handler for this method. Which seems quite logical.

[gfreeau]

@slashfan I agree, I tried to make a ticket about this: symfony/symfony#11451

If the built in symfony listeners supported stateless and success handlers, the gfreeau bundle wouldn't be needed.

The GfreeauGetJWTBundle could be rebranded as a generic listener that takes a username/password and then fires a success listener which is our case would be the lexikjwt success listener.

This is a better solution than bringing into your bundle I think.

I was seeing if we could get something like that into symfony core.

[slashfan]

@gfreeau I saw that ticket, I thought it was a good idea, at least it is now open for debate ! I'll let you decide what to do with the GfreeauGetJWTBundle, but in the meantime I'll add a link to it in the doc, along with an explanation about the problem it's intended to solve.

[slashfan]

I just added CORS requests help and a link and introduction to the GfreeauGetJWTBundle.

[arendjantetteroo]

Nice, thanks!

[slashfan]

@arendjantetteroo I tried on Apache and I have the same problem. Does the stackoverflow solution works for you ? I can't get it to work.

[arendjantetteroo]

I added this to my .htaccess

# Allow authorization header onto the sf2 app, needed for api jwt token authorization
RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule .* - [e=HTTP_AUTHORIZATION:%1]

Based on this stackoverflow answer : http://stackoverflow.com/questions/13387516/authorization-header-missing-in-django-rest-framework-is-apache-to-blame

And that works with the token I get through the getJwtBundle.

This is my security.yml

gettoken:
        pattern:  ^/api/getToken$
        stateless: true
        gfreeau_get_jwt:
            username_parameter: username
            password_parameter: password
            post_only: true
            success_handler: lexik_jwt_authentication.handler.authentication_success
            failure_handler: lexik_jwt_authentication.handler.authentication_failure

api:
      pattern:   ^/api
      stateless: true
      lexik_jwt:
        authorization_header: # check token in Authorization Header
            enabled: true
            prefix:  Bearer
        query_parameter:      # check token in query string parameter
            enabled: true
            name:    bearer
        throw_exceptions: false     # When an authentication failure occurs, return a 401 response immediately
        create_entry_point: true    # When no authentication details are provided, create a default entry point that returns a 401 response

I'll see if i can try it with the form login approach of just the lexik bundle alone

[slashfan]

My mistake ! I added the rules to the .htaccess instead of the virtualhost configuration !
But thanks for the reply !

[arendjantetteroo]

No problem, glad you could reproduce the issue :)

[slashfan]

If it's ok with you I'm gonna add it to the documentation as I'm on it !

[arendjantetteroo]

Sure, please do. I have no more time today.

[slashfan]

Done ! Is it ok to close this issue ?

[arendjantetteroo]

Excellent, Thanks.
Op 10 aug. 2014 15:49 schreef "Nicolas Cabot" [email protected]:

Done ! Is it ok to close this issue ?

—
Reply to this email directly or view it on GitHub
#23 (comment)
.