Sylius: [SyliusApiBundle] Api-Calls bypasses token based authentication and always redirects to /connect

[itinance]

As described in the API-related Docs for Authentication, everything works fine when it comes to register a new api client and to retrieve an access token for an existing user.

Anyway, it is not possible to execute any API-call with the access_token passed as "Authentication"-Header. Every api call will be responded with a 301-redirect to the /connect-Route, which offers 3 links to connect with amazon, google and facebook and which seems to come from HWI-OAuth-Bundle.
Also it does not matter weather an Authentication-Header is passed or not or if it contains valid characters or not.

While investigating this issue i stumbled upon this question at stackoverflow which describes nearly the same behaviour.

I also tried this out with a completely new sylius installation based on 0.17.0.

Steps to reproduce:

I. api client creation with all grant types:

php app/console sylius:oauth-server:create-client --grant-type="password" --grant-type="refresh_token" --grant-type="token"
_Output:_

A new client with public id 1vfmrpbwbkjooksgwo0s8sowck08skww4o8o0c4ccgg88o04sw, secret 22oew12ifockko4skogw0kc80g0084w8s8swock0kocccg8scc has been added

II. retrieve access token

curl http://www.example.dev/oauth/v2/token \
    -d "client_id"=1vfmrpbwbkjooksgwo0s8sowck08skww4o8o0c4ccgg88o04sw \
    -d "client_secret"=22oew12ifockko4skogw0kc80g0084w8s8swock0kocccg8scc \
    -d "grant_type"=password \
    -d "username"[email protected] \
    -d "password"=example

This is a valid user which is able to being logged in. More concretely this user is the admin user which was created at the installation process of sylius.

_Output:_

{"access_token":"OWY5MjZhMzdlMzc0ZTBiMWIyMTQzMjdiMTFlOTI5NzBiYmFjYzYwZTEyMGU1NmZhZTViMjY5OThmYmY3NGIzNw","expires_in":3600,"token_type":"bearer","scope":null,"refresh_token":"ZjBiOTkwZjFjMjA4M2NjYzRmZDhjM2Q5NzdmYjE1MDA1MGE5N2ZjY2UxYTJmZmI5NmEwNzBjOTAyMTQ4N2I5Ng"}

III. use the access token for any api request:

curl http://www.example.dev/api/users -H "Authorization: Bearer OWY5MjZhMzdlMzc0ZTBiMWIyMTQzMjdiMTFlOTI5NzBiYmFjYzYwZTEyMGU1NmZhZTViMjY5OThmYmY3NGIzNw"
The Response is a redirect 301 to the http://www.example.dev/connect

This is my security.yml:

# This file is part of the Sylius package.
# (c) Paweł Jędrzejewski

security:
    providers:
        sylius_user_provider:
            id: sylius.user_provider.name_or_email
    encoders:
        Sylius\Component\User\Model\UserInterface: sha512
    firewalls:
        administration:
            switch_user: true
            context:     user
            pattern:     /administration/.*
            form_login:
                provider:     sylius_user_provider
                login_path:   /administration/login
                check_path:   /administration/login-check
                failure_path: /administration/login
                default_target_path: /administration/dashboard
                use_forward:  false
                use_referer:  true
            logout:
                path:   /administration/logout
                target: /administration/login
            anonymous: true

        main:
            switch_user: { role: ROLE_SYLIUS_ADMIN }
            context:     user
            pattern:     /.*
            form_login:
                provider: sylius_user_provider
                login_path: /login
                check_path: /login_check
                failure_path: /login
                default_target_path: /
                use_forward:  false
                use_referer: true
            remember_me:
                key: %sylius.secret%
                name: APP_REMEMBER_ME
                lifetime: 31536000
                always_remember_me: true
                remember_me_parameter: _remember_me
            oauth:
                resource_owners:
                    amazon:   "/login/check-amazon"
                    facebook: "/login/check-facebook"
                    google:   "/login/check-google"
                login_path:   /connect
                failure_path: /connect
                oauth_user_provider:
                    service: sylius.oauth.user_provider
            logout: true
            anonymous: true

        dev:
            pattern:  ^/(_(profiler|wdt)|css|images|js)/
            security: false

    access_control:
        - { path: ^/api, role: ROLE_API }
        - { path: ^/login.*, role: IS_AUTHENTICATED_ANONYMOUSLY }
        - { path: ^/connect.*, role: IS_AUTHENTICATED_ANONYMOUSLY }
        - { path: ^/register, role: IS_AUTHENTICATED_ANONYMOUSLY }
        - { path: ^/resetting, role: IS_AUTHENTICATED_ANONYMOUSLY }

        - { path: ^/administration/login, role: IS_AUTHENTICATED_ANONYMOUSLY }
        - { path: ^/administration/login-check, role: IS_AUTHENTICATED_ANONYMOUSLY }
        - { path: "/administration.*", role: ROLE_ADMINISTRATION_ACCESS }

        - { path: "/account.*", role: ROLE_USER }

        - { path: "/_partial.*", ip: 127.0.0.1 }

And the roles of the user are:

a:2:{i:0;s:9:"ROLE_USER";i:1;s:8:"ROLE_API";}

[liverbool]

You need to grant ROLE_API for [email protected].

• Access to /administration/roles/ create new one or edit eg. API Role.
• Check Can access REST API in form and save.
• Access to /administration/customers/ edit [email protected] by check API Role in roles.

Seems ROLE_API not granted to [email protected] by default fixture.

My personal solution: Extend User Model then return User's roles with append ROLE_API by default.

[itinance]

Thx, but this doesn't help. The issue remains. I found out that the Usermodel isn't used at those api calls. I can put some die()'s into the constructor or into "getRoles"-Method and they won't being catched.

I hooked directly into vendor/sylius/sylius/src/Sylius/Component/User/Model/User.php and can do anything i want there. Even after cache:clear this Model is not touched when making an api call like /api/users.

I guess that the redirect happens something else before the user authentication.

[liverbool]

Oh, It's work for me.

The ^/api path protected with ROLE_API (app/config/security.yml):

access_control:
    - { path: ^/api, role: ROLE_API }

My solution just add ROLE_API for user who access to it.

[itinance]

This entry wasn't part of the security.yml, but even if I add it, the behaviour doesn't change either.

[itinance]

I've added my security.yml and the roles of the user to the main/first comment of this issue

[lchrusciel]

We have some tests for API here and everything works fine. I will investigate it further today.

[itinance]

I pushed a fresh sylius installation to github together with a database and my own apitest (based on curl and php): https://github.com/itinance/sylius_apicheck

I did the installation following the official documentation:

composer create-project -s dev sylius/sylius-standard apitest
cd apitest
php app/console sylius:install
php app/console server:run

php app/console sylius:oauth-server:create-client \
    --grant-type="password" \
    --grant-type="refresh_token" \
    --grant-type="token"

A new client with public id 5yw7k9iwhvk0wwoc00g08c0s0kwso0sgkw0cso4ws0wkkk80go, secret 3pbg70ptq1q8wkcgwgows8s0c0wcow4c84084oo4s4c0cssss0 has been added

The database contains already an api-client and a user:

Username: [email protected]
Password: api

The idea here was to run the app with php's builtin server and to fire some app-calls against localhost:8000: https://github.com/itinance/sylius_apicheck/blob/master/apitest.php

Maybe it helps for investigation.

[lchrusciel]

Ok. I've found out what cause your problem. Everything works fine on Sylius side. But from the beginning. You have send following request:

curl http://www.example.dev/api/users -H "Authorization: Bearer OWY5MjZhMzdlMzc0ZTBiMWIyMTQzMjdiMTFlOTI5NzBiYmFjYzYwZTEyMGU1NmZhZTViMjY5OThmYmY3NGIzNw"

And you have received something similar to this message:

<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8" />
        <meta http-equiv="refresh" content="1;url=http://127.0.0.1:8000/api/users/" />

        <title>Redirecting to http://127.0.0.1:8000/api/users/</title>
    </head>
    <body>
        Redirecting to <a href="http://127.0.0.1:8000/api/users/">http://127.0.0.1:8000/api/users/</a>.
    </body>
</html>

It is a proper behaviour, because we present a collection of resources under /api/users/ url instead of /api/users. FOSRestBundle provides logic to automatic redirect if you would send request under following URL. And thats why you have received that message. As you can see here for example all endpoints which should present a collection of resources have a / at the end.
To make it work it will be enough to send requests to http://127.0.0.1:8000/api/users/ or add -L flag to your curl call

curl http://127.0.0.1:8000/api/users -H "Authorization: Bearer N2RiYWE0ZWI5NGNiZDg2YzAyOTllNWY4NjU5ODUwZGQ1Y2ZiNTFkODRhZmE2NTAyYzEyYzAyOTMxZjE5ZTdiZg" -H "Accept: application/json" -L 

[itinance]

Thx for reply. When adding the missing Slash, the previous described behaviour occured with a 301-redirect to "/connect":

<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8" />
        <meta http-equiv="refresh" content="1;url=http://localhost:8000/connect" />

        <title>Redirecting to http://localhost:8000/connect</title>
    </head>
    <body>
        Redirecting to <a href="http://localhost:8000/connect">http://localhost:8000/connect</a>.
    </body>
</html>

[lchrusciel]

And now you have same issue as submitted at StackOverFlow. I haven't been able to reproduce your issue. Can you check this command

curl http://127.0.0.1:8000/api/users -H "Authorization: Bearer N2RiYWE0ZWI5NGNiZDg2YzAyOTllNWY4NjU5ODUwZGQ1Y2ZiNTFkODRhZmE2NTAyYzEyYzAyOTMxZjE5ZTdiZg" -H "Accept: application/json" -L

[lchrusciel]

And also, can you check the following command:

curl http://127.0.0.1:8000/oauth/v2/token \
-d  "client_id”=generatedtoken \
-d "client_secret”=generatedsecret \
-d "grant_type”=password \
-d "username”[email protected] \
-d "password”=api

User [email protected] with api password is a default user with an API access

[itinance]

As you can see in my automated test, i was already testing with [email protected] with api-password and also with the Accept-Header and also now with -L option.

Both, my script and also your requested curl-call, return the full page behind the url "/connect" (and certainly without -L option only the 301-redirect without automatic redirect).
I guess, that hwi-oauth will do something strange here because the page behind "/connect" contains 3 links to connect with amazon and facebook and so on. Could it be?

For the sake of completeness: i can reproduce it right now at any time. I also setup a complete new debian box and setup everything from scratch. The behaviour remains the same

[lchrusciel]

Thats weird, because I don't have any troubles to access Sylius API. Have you checked the latest version of Sylius?

[itinance]

After switching from "sylius/sylius-standard" to "sylius/sylius" in "composer create-project -s dev" and the installation of sample data i could fire a valid request to "/api/users/", but got "403 access denied".

One difference i've found is that there is a group called "API" now in sample data. I assigned this group to the user "[email protected]". The user is enabled and part of the role "administrator". Also i selected the group "administrator" to the user.

But i still get a 403:

{"code":403,"message":"Access Denied."}

Anyhow, i think we are one step further. It's a thing of roles and groups and permissions i guess

[lchrusciel]

I will check it further tomorrow morning probably. Thanks for reporting.

[michalmarcinkowski]

The security.yml file on Sylius-Standard is not updated and that is probably the issue here. @itinance try to copy security.yml file from Sylius/Sylius repository and check if it works.

[itinance]

@michalmarcinkowski i've updated the security.yml, but every request get's a html page with title "Access Denied. (403 Forbidden)" and the symfony2-stacktrace (debug-mode enabled). The used user is the administrator.
I am wondering about that the response is a plain html page as i would call a page via webbrowser instead of a rest-call per json (curl with -H "Accept: application/json")

[itinance]

Is there a special group necessary or further specific permissions? in my database there are no groups available to assign to the user. @michalmarcinkowski @lchrusciel

[lchrusciel]

You need ROLE_API_ACCESS to be able to send requests. You can check fixtures for that

[ping86]

@lchrusciel @itinance I have the same issue with sylius-standar 0.17.0

I have all api roles, a:3:{i:0;s:9:"ROLE_USER";i:1;s:15:"ROLE_API_ACCESS";i:2;s:8:"ROLE_API";}

I do:

curl -v -H "Accept: application/json" -H 'Authorization: Bearer NjYwNjNlZGYwNzZhZDgzYzljYWIzYWQwOTY2YTA0ZGY5MjNhZTM5YjhjM2Q5YmRlNDk2MDAzM2U2MjE4NjYxYg' http://localhost/sylius-standard/web/app_dev.php/api/taxonomies/?limit=100

But we receive a redirect to connect page:

* Connected to localhost (127.0.0.1) port 80 (#0)
> GET /sylius-standard/web/app_dev.php/api/taxonomies/?limit=100 HTTP/1.1
> User-Agent: curl/7.35.0
> Host: localhost
> Accept: application/json
> Authorization: Bearer NjYwNjNlZGYwNzZhZDgzYzljYWIzYWQwOTY2YTA0ZGY5MjNhZTM5YjhjM2Q5YmRlNDk2MDAzM2U2MjE4NjYxYg
> 
< HTTP/1.1 302 Found
< Date: Thu, 14 Apr 2016 07:57:25 GMT
* Server Apache/2.4.7 (Ubuntu) is not blacklisted
< Server: Apache/2.4.7 (Ubuntu)
< X-Powered-By: PHP/5.6.19-1+deb.sury.org~trusty+1
< Set-Cookie: PHPSESSID=oh4t0mm1uqmccrf8gb17ovbbh1; path=/; HttpOnly
< Cache-Control: no-cache
< Location: http://localhost/sylius-standard/web/app_dev.php/connect
< X-Debug-Token: b9e4c0
< X-Debug-Token-Link: /sylius-standard/web/app_dev.php/_profiler/b9e4c0
< Content-Length: 468
< Content-Type: text/html; charset=UTF-8
< 
<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8" />
        <meta http-equiv="refresh" content="1;url=http://localhost/sylius-standard/web/app_dev.php/connect" />

        <title>Redirecting to http://localhost/sylius-standard/web/app_dev.php/connect</title>
    </head>
    <body>
        Redirecting to <a href="http://localhost/sylius-standard/web/app_dev.php/connect">http://localhost/sylius-standard/web/app_dev.php/connect</a>.
    </body>
* Connection #0 to host localhost left intac

[itinance]

@lchrusciel i've added ROLE_API_ACCESS to the roles-field of the user according to @ping86's example:

a:3:{i:0;s:9:"ROLE_USER";i:1;s:15:"ROLE_API_ACCESS";i:2;s:8:"ROLE_API";}

Also i added the Sylius-Role "ROLE_API_ACCESS" to the user and gave it root-permissions and api-access-permissions.

For me everything remains with Access Denied. Retrieving an access token works pretty fine, and if this token expires, every API-Request send a response stating that token has expired (as expected).

But on valid access tokens, some firewall (or whatever else) will deny the access to api layer.

[itinance]

@ping86 have you replaced your security.yml file with the content of that from the Sylius/Sylius repository (as mentioned by @lchrusciel some comments before)? Please try this one: https://github.com/Sylius/Sylius/blob/master/app/config/security.yml

Than you should be able to go one step ahead, which means: no rediretion to "/connect" any more, but Access-Denied errors on API-Requests with valid access_token.

[itinance]

Found this bug from Jan 12: https://github.com/Sylius/Sylius/issues/3815, maybe it's related?

[liverbool]

Confirmed! #3815 Can fix this issue.

Sorry for my mistake about ROLE_API, Sylius~0.17 use ROLE_API_ACCESS.

[liverbool]

This's security.yml for Sylius 0.17

https://github.com/Sylius/Sylius/blob/v0.17.0/app/config/security.yml

[ping86]

@liverbool I use this security.yml, I create new proyect, I use [email protected] fixtures user, I do all acctions in documentation but dont work.

[1] Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException: Access Denied.
    at n/a
        in /var/www/acme/vendor/symfony/symfony/src/Symfony/Component/Security/Http/Firewall/ExceptionListener.php line 119

    at Symfony\Component\Security\Http\Firewall\ExceptionListener->handleAccessDeniedException(object(GetResponseForExceptionEvent), object(AccessDeniedException))
        in /var/www/acme/vendor/symfony/symfony/src/Symfony/Component/Security/Http/Firewall/ExceptionListener.php line 97

    at Symfony\Component\Security\Http\Firewall\ExceptionListener->onKernelException(object(GetResponseForExceptionEvent), 'kernel.exception', object(TraceableEventDispatcher))
        in  line 

    at call_user_func(array(object(ExceptionListener), 'onKernelException'), object(GetResponseForExceptionEvent), 'kernel.exception', object(TraceableEventDispatcher))
        in /var/www/acme/vendor/symfony/symfony/src/Symfony/Component/EventDispatcher/Debug/WrappedListener.php line 61

    at Symfony\Component\EventDispatcher\Debug\WrappedListener->__invoke(object(GetResponseForExceptionEvent), 'kernel.exception', object(ContainerAwareEventDispatcher))
        in  line 

    at call_user_func(object(WrappedListener), object(GetResponseForExceptionEvent), 'kernel.exception', object(ContainerAwareEventDispatcher))
        in /var/www/acme/app/cache/dev/classes.php line 4660

    at Symfony\Component\EventDispatcher\EventDispatcher->doDispatch(array(object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener)), 'kernel.exception', object(GetResponseForExceptionEvent))
        in /var/www/acme/app/cache/dev/classes.php line 4578

    at Symfony\Component\EventDispatcher\EventDispatcher->dispatch('kernel.exception', object(GetResponseForExceptionEvent))
        in /var/www/acme/vendor/symfony/symfony/src/Symfony/Component/EventDispatcher/Debug/TraceableEventDispatcher.php line 132

    at Symfony\Component\EventDispatcher\Debug\TraceableEventDispatcher->dispatch('kernel.exception', object(GetResponseForExceptionEvent))
        in /var/www/acme/app/bootstrap.php.cache line 3242

    at Symfony\Component\HttpKernel\HttpKernel->handleException(object(AccessDeniedException), object(Request), '1')
        in /var/www/acme/app/bootstrap.php.cache line 3178

    at Symfony\Component\HttpKernel\HttpKernel->handle(object(Request), '1', true)
        in /var/www/acme/app/bootstrap.php.cache line 3323

    at Symfony\Component\HttpKernel\DependencyInjection\ContainerAwareHttpKernel->handle(object(Request), '1', true)
        in /var/www/acme/app/bootstrap.php.cache line 2511

    at Symfony\Component\HttpKernel\Kernel->handle(object(Request))
        in /var/www/acme/web/app_dev.php line 22

[2] Symfony\Component\Security\Core\Exception\AccessDeniedException: Access Denied.
    at n/a
        in /var/www/acme/vendor/sylius/sylius/src/Sylius/Bundle/ResourceBundle/Controller/ResourceController.php line 507

    at Sylius\Bundle\ResourceBundle\Controller\ResourceController->isGrantedOr403(object(RequestConfiguration), 'index')
        in /var/www/acme/vendor/sylius/sylius/src/Sylius/Bundle/ResourceBundle/Controller/ResourceController.php line 193

    at Sylius\Bundle\ResourceBundle\Controller\ResourceController->indexAction(object(Request))
        in  line 

    at call_user_func_array(array(object(UserController), 'indexAction'), array(object(Request)))
        in /var/www/acme/app/bootstrap.php.cache line 3210

    at Symfony\Component\HttpKernel\HttpKernel->handleRaw(object(Request), '1')
        in /var/www/acme/app/bootstrap.php.cache line 3172

    at Symfony\Component\HttpKernel\HttpKernel->handle(object(Request), '1', true)
        in /var/www/acme/app/bootstrap.php.cache line 3323

    at Symfony\Component\HttpKernel\DependencyInjection\ContainerAwareHttpKernel->handle(object(Request), '1', true)
        in /var/www/acme/app/bootstrap.php.cache line 2511

    at Symfony\Component\HttpKernel\Kernel->handle(object(Request))
        in /var/www/acme/web/app_dev.php line 22

[liverbool]

You need to patch your rbac by following #3815

Override your rbac

# app/config.yml

sylius_rbac:
    ....

Update Rbac

$ php app/console sylius:rbac:initialize

[itinance]

@liverbool What content should "sylius_rbac"-node have? is there any documentation about?

[liverbool]

@itinance see in https://github.com/Sylius/Sylius/pull/3885

[ping86]

Thanks, now the api works.

curl http://localhost/acme/web/app_dev.php/api/users/ -H "Accept: application/json" -H "Content-Type: application/json" -H "Authorization: Bearer NzY0ZWQ4YjI3OWMyNTliNTQ4NjNiNTI2YjIzYzgyNGQ0M2JkNmQxYzcwM2RmNTdkOTQ0MWMxZTM5OGJkMWM4MA"

{"page":1,"limit":10,"pages":21,"total":202,"_links":{"self":{"href":"\/acme\/web\/app_dev.php\/api\/users\/?page=1&limit=10"},"first":{"href":"\/acme\/web\/app_dev.php\/api\/users\/?page=1&limit=10"},"last":{"href":"\/acme\/web\/app_dev.php\/api\/users\/?page=21&limit=10"},"next":{"href":"\/acme\/web\/app_dev.php\/api\/users\/?page=2&limit=10"}},"_embedded":{"items":[{"id":203,"username":"[email protected]","username_canonical":"[email protected]","roles":["ROLE_USER","ROLE_API_ACCESS","ROLE_API"],"enabled":true},{"id":202,"username":"[email protected]","username_canonical":"[email protected]","roles":["ROLE_USER"],"enabled":true},{"id":201,"username":"[email protected]","username_canonical":"[email protected]","roles":["ROLE_USER"],"enabled":true},{"id":200,"username":"[email protected]","username_canonical":"[email protected]","roles":["ROLE_USER"],"enabled":true},{"id":199,"username":"[email protected]","username_canonical":"[email protected]","roles":["ROLE_USER"],"enabled":false},{"id":198,"username":"[email protected]","username_canonical":"[email protected]","roles":["ROLE_USER"],"enabled":false},{"id":197,"username":"[email protected]","username_canonical":"[email protected]","roles":["ROLE_USER"],"enabled":false},{"id":196,"username":"[email protected]","username_canonical":"[email protected]","roles":["ROLE_USER"],"enabled":true},{"id":195,"username":"[email protected]","username_canonical":"[email protected]","roles":["ROLE_USER"],"enabled":false},{"id":194,"username":"[email protected]","username_canonical":"[email protected]","roles":["ROLE_USER"],"enabled":true}]}}

But you need configure FOSrestbundle and install SensioFrameworkExtraBundle.

If you dont configure and install you see the following error:

curl http://localhost/acme/web/app_dev.php/api/users/ -H "Accept: application/json" -H "Content-Type: application/json" -H "Authorization: Bearer NzY0ZWQ4YjI3OWMyNTliNTQ4NjNiNTI2YjIzYzgyNGQ0M2JkNmQxYzcwM2RmNTdkOTQ0MWMxZTM5OGJkMWM4MA"

I have the following error:

Unable to find template "SyliusWebBundle:Frontend/User:index.twig".

500 Internal Server Error - InvalidArgumentException
3 linked Exceptions:
Twig_Error_Loader »
InvalidArgumentException »
InvalidArgumentException »

[ylastapis]

Hi @ping86

What are your final updates ? I've followed all I can in this discussion but i'm still stuck on the access_denied error.

To sum up :

• I've updated my security.yml with this one https://github.com/Sylius/Sylius/blob/v0.17.0/app/config/security.yml
• I've overrided the sylius_rbac section by following

sylius_rbac:
    permissions:
        sylius.manage.user: Manage users
        sylius.user.show: Show user
        sylius.user.index: List user
        sylius.user.create: Create user
        sylius.user.update: Edit user
        sylius.user.delete: Delete user
    permissions_hierarchy:
        sylius.manage.user: [sylius.user.show, sylius.user.index, sylius.user.create, sylius.user.update, sylius.user.delete]
        sylius.security: [sylius.manage.user, sylius.manage.permission, sylius.manage.role, sylius.manage.customer, sylius.manage.group, sylius.accounts]
    roles:
        administrator:
            permissions: [sylius.manage.settings, sylius.manage.locale, sylius.manage.currency, sylius.manage.country, sylius.manage.province, sylius.manage.zone, sylius.manage.payment_method, sylius.manage.channel, sylius.manage.user]

and ran the command to import new rights

$ php app/console sylius:rbac:initialize

The log said new lines have been correctly imported

• I use the gist from @itinance here https://github.com/itinance/sylius_apicheck/blob/master/apitest.php either as REST clients, but the results is always the same:

Access-Token: xxx...xxx: bearer
string '{"error":"access_denied","error_description":"OAuth2 authentication required"}' (length=78)

Weird things I've noted which does not solve my problem anyhow:

• [email protected] is not part of any group
• ROLE_API_ACCESS is not used and there is not a single role having this granted
• sylius.manage.api_client is affected only to role developer, why not to admin user ?

Trying to connect as an Administrator granted with ROLE_API_ACCESS, ROLE_ADMINISTRATION_ACCESS and sylius.manage.api_client does'n give a clue either

[michalmarcinkowski]

The configuration on Sylius-Standard was outdated and could lead to these errors, make sure you have all configuration files updated to the newest version (see PR with update here).

[ylastapis]

Hi @michalmarcinkowski and thanks for your feedback.

I changed my composer conf from "sylius/sylius": "0.17.*@dev", to "sylius/sylius": "dev-master",

Thus, following changes have occured

  - Removing a2lix/translation-form-bundle (2.1.2)
  - Installing webmozart/assert (1.0.2)
    Loading from cache

  - Removing friendsofsymfony/rest-bundle (1.7.7)
  - Installing friendsofsymfony/rest-bundle (1.7.8)
    Loading from cache

  - Removing sylius/sylius (v0.17.0)
  - Installing sylius/sylius (dev-master 9bb3f1d)
    Cloning 9bb3f1df717a02dd3f866f755c6960c6ea25627e

  - Updating sensio/framework-extra-bundle (v3.0.16 => v3.0.12)
    Checking out 3e8936fe13aa4086644977d334d8fcd275f50357

Now I've got your last changes but that does not change anything.

I'm trying a new fresh install right now

[ylastapis]

Well, I've tried both composer create-project -s dev sylius/sylius-standard or composer create-project -s dev sylius/sylius then php app/console sylius:install

The behavior is the same as described by @itinance

1st call will works and return an access token with token_type = bearer

curl -sS http://dev:8888/app_dev.php/oauth/v2/token \
-d "client_id"=demo_client \
-d "client_secret"=secret_demo_client \
-d "grant_type"=password \
-d "username"[email protected] \
-d "password"=api

The next call always raise an access_denied exception

curl -sS http://syliuscontribute:8888/app_dev.php/api/users/ -H "Accept: application/json" "Content-Type: application/json" -H "Authorization: $tokenType $accessToken" -L

overriding sylius_rbac section does not resolve the problem.

[michalmarcinkowski]

Verified that #4833 fixes this issue.

[pjedrzejewski]

Hi @itinance, thanks for reporting. Please reopen if you still have any problems. Remember to do app/console sylius:rbac:initialize to load new permissions.

[itinance]

After applying the patch of sylius.yml from #4833 and an "app/console sylius:rbac:initialize" the behaviour changed from access denied to a plain 500er.
I called the "/api/users/"-Endpoint.

Unable to find template "SyliusWebBundle:Frontend/User:index.twig" (looked into: /data/workspace/XXX/Backend/app/Resources/views, /data/workspace/XXX/Backend/vendor/symfony/symfony/src/Symfony/Bridge/Twig/Resources/views/Form, /data/workspace/XXXX/Backend/vendor/knplabs/knp-menu/src/Knp/Menu/Resources/views). (500 Internal Server Error)

Don't know why an api-call needs a twig-file...

[pjedrzejewski]

Do you have fos_rest configured correctly?

[itinance]

Don't know :) I just installed sylius and followed instructions from sylius documentation.
Is there anything else to know about and/or to consider?

[pix-art]

I had the same issue, and after a while I noticed when I passed "access_token=xxxx" in my url it did work, So i knew something was wrong on the PHP end.
Long story short, apache didn't know the "Authorization: Bearer" header so it stripped it.
When I added this to my htaccess it worked:

    RewriteEngine On

    RewriteCond %{HTTP:Authorization} ^(.*)
    RewriteRule .* - [e=HTTP_AUTHORIZATION:%1]

[pjedrzejewski]

@TheMadeleine We should have @pix-art's solution in the docs.

[pix-art]

@pjedrzejewski why don't we add my solution to the .htaccess? that way we don't have to document it?

[pjedrzejewski]

@pix-art @TheMadeleine Can someone you open a PR, please? Thanks!

[pix-art]

@pjedrzejewski On it