I would like to authenticate the user through an API (external user provider) running my integration tests.
my config_test.yml
imports:
- { resource: config.yml }
- { resource: parameters_test.yml }
framework:
test: ~
session:
storage_id: session.storage.mock_file
monolog:
handlers:
main:
type: stream
path: %kernel.logs_dir%/%kernel.environment%.log
level: info
After the login (SUCCEED) the next step is ask for user information and I got:
"Full authentication is required to access this resource."
I guess something is happening with the stored session.
I am using Redis on dev and prod to store sessions.
Mocking sessions on the test environment because of
"Failed to start the session because headers have already been sent by "/path/to/bin/phpunit" at line 2."
Doing it manually is working like a charm.
session.storage.mock_file uses by default %kernel.cache_dir%/sessions for a storing of session's file. Check if this folder is writable for both server user and cli user.
'Setting up Permissions' http://symfony.com/doc/current/book/installation.html#configuration-and-setup
Another 2 possible reasons of error:
stateless: true on your firewall in firewalls section. The ContextListener is not created and Token is not saved to the session. AnonymousToken is assigned to next request.
stateless: true you also can have RememberMeToken instead of AnonymousToken if remember_me feature enabled. This token is also not full fledged.
UPDATE
Ensure that intercept_redirects is false in config_test.yml as it may break all redirects.
web_profiler:
toolbar: false
intercept_redirects: false
Related
I think I reached some limit with the Symfony security component. Here's my problem: I have two firewall to manage two users type (with two distinct entities) authentication and access to two different part of the website. I have a third part to manage files, uploads, ... that have to be private and both users types need to access it.
So I made multiple providers in security.yml:
providers:
# used to reload user from session & other features (e.g. switch_user)
core_user_provider:
entity:
class: Akyos\CoreBundle\Entity\User
property: email
platform_user_provider:
entity:
class: App\Entity\Platform\UserPlatform
property: email
file_manager_provider:
chain:
providers: [core_user_provider, platform_user_provider]
And multiple firewalls
firewalls:
dev:
pattern: ^/(_(profiler|wdt)|css|images|js)/
security: false
core:
pattern: ^/(app|admin)/
context: shared
provider: core_user_provider
anonymous: lazy
guard:
authenticators:
- Akyos\CoreBundle\Security\CoreBundleAuthenticator
logout:
path: app_logout
target: 'home'
remember_me:
secret: '%kernel.secret%'
lifetime: 604800 # 1 week in seconds
path: /
file_manager:
pattern: ^/(file-manager)
context: shared
provider: file_manager_provider
anonymous: lazy
guard:
authenticators:
- App\Security\FileManagerAuthenticator
logout:
path: file_manager_logout
target: 'home'
remember_me:
secret: '%kernel.secret%'
lifetime: 604800 # 1 week in seconds
path: /
platform:
pattern: ^/(platorm_login|plateforme)
context: shared
provider: platform_user_provider
anonymous: lazy
guard:
authenticators:
- App\Security\PlatformAuthenticator
logout:
path: platform_logout
target: 'home'
remember_me:
secret: '%kernel.secret%'
lifetime: 604800 # 1 week in seconds
path: /
main:
anonymous: lazy
So a Platform user can't access Core, and a Core user can't access Platform. But both users needs to access File-manager, without re-log in. I can't place /file-manager urls under Core or Platform firewall because the other wouldn't grant access to it. So I need a third firewall to manage File-manager access. It use a chain provider that groups both Core and Platform users. It doesn't work either because if a Core user authenticate through the Core firewall it is not authenticated for the File-manager one, so it redirect to File-manager login page.. if the user logs in File-manager part it can access it, but when it turn back to Core part it has to re-connect again.
I tried several things but the closest solution is to use the context option on firewalls, so when a user is logged in through Core part it can access File-manager part without re-log because both firewalls shared the same context. That's what I want. But I also need it for the Platform firewall! So I also add same context option to it, and it works, both users types can access File-manager without log in again :D But as the three firewalls share the same context, Core users can access to Platform and vice-versa, and that breaks all the separation logic.. :'(
I need a way to tell security component "File-manager firewall has same context as Core firewall, and File-manager firewall has same context as Platform firewall, but Core and Platform firewalls doesn't share the same context". Something like this:
firewalls:
core:
context: core
file_manager:
context: [core,platform]
platform:
context: platform
main:
anonymous: lazy
I found nothing about it. Maybe it can't be done, maybe I have to create custom provider or authenticator to hack it. Maybe I can make it without Symfony, it's only php after all, so could I make the file-manager part accessible to every one (so under the main firewall) and add a Listener that would check if the request is for file-manager, find in session if there is a previous logged-in user, check if the user is a Core or a Platform user and then redirect if not... ? How can I find the previous Core or Platform user in session, when on a "main firewall" page (= authenticated as anonymous), without Symfony functions ? I'm not good enough to know how I could achieve that. Help ?
Thanks
I've finally let 3 providers and firewalls with context shared between it. To prevent Core users to access Platform, and vice-versa, I added access_control:
- { path: ^/file-manager, roles: [ROLE_PLATFORM, ROLE_CORE] }
- { path: ^/core, roles: ROLE_CORE }
- { path: ^/plateforme, roles: ROLE_PLATFORM }
so it ends with a 403 access denied error. That's not the behavior I want so I also added 'access_denied_url' option on both core and platform firewall to redirect user on the good login page. As contexts are shared, users are already logged, so on login template I check instance of user object to advice him to disconnect first before trying to access this part.
{% if instanceOf(app.user, 'App\\Entity\\PlatformUser') %}
You're already logged in Platform space, please log out before access Core space.
{% else %}
You're already logged in as {{ app.user.username }}, log out or access core panel.
{% endif %}
It's a bit confusing to have context shared between parts that shouldn't share anything but access to file-manager, but no user can access other part so.. that works.
In my Symfony project I have a members zone accessible only by logged users then I write this in my security.yml (access_control):
{ path: ^/membre/, role: IS_AUTHENTICATED_REMEMBERED }
I did too a form with fos_user_security_check action and a _target_path = detail_page_membre.
When I try to log my user, I was redirected to / and in my log I have this:
User has been authenticated successfully. {"username":"toto"} []
Matched route "detail_page_membre".
Populated the TokenStorage with an anonymous Token.
Access denied, the user is not fully authenticated; redirecting to
authentication entry point.
I don't have write any firewalls maybe it's this?
This issue often happens because of the session:
check your session configuration under framework in config.php file:
framework:
session:
# handler_id set to null will use default session handler from php.ini
handler_id: ~
Read more:
Logging in redirects to the login page with no errors
Symfony2 - Access is denied (user is not fully authenticated)
This question may have been asked before. I have searched for answers, but I haven't found what I was looking for.
In Symfony 2.3, is there a way to disable the logger for specific requests? I mean, I am using a SOAP service for my project. When I send a request to login, the username and password are dumped straight as plain text into the log file. Is there a way to stop logging this kind of specific requests?
For example, when I send a request for login, the logger should be disabled, but for all other request it works again. Is this possible?
depending if your are in Prod or Dev environement but everything is in config.yml or config_dev.yml :
to disable logging just remove monolog configuration like this :
monolog:
handlers:
main:
type: stream
path: "%kernel.logs_dir%/%kernel.environment%.log"
level: debug
console:
type: console
bubble: false
# uncomment to get logging in your browser
# you may have to allow bigger header sizes in your Web server configuration
#firephp:
# type: firephp
# level: info
#chromephp:
# type: chromephp
# level: info
but in my opinion , you shouln't do this because logging allows you to improve significantly your code !
Logging except for a specific service :
You need to create a specific log channel for your service as described there :
http://symfony.com/doc/current/cookbook/logging/channels_handlers.html
and there :
http://symfony.com/doc/current/reference/dic_tags.html#dic-tags-monolog
you ll be able to separate your soap log from others and eventually send it to null
I'm configuring a Symfony2 application using the FOSUserBundle to use http_digest authentication. This is with Symfony 2.1.0-BETA2.
In security.yml, I am simply switching out http_basic for http_digest and adding the required key property. All else remains the same.
Relevant configuration that works:
firewalls:
main:
pattern: ^/
anonymous: ~
form_login: false
provider: fos_user_bundle
http_basic:
realm: "Example Realm"
Relevant configuration that does not work:
firewalls:
main:
pattern: ^/
anonymous: ~
form_login: false
provider: fos_user_bundle
http_digest:
realm: "Example Realm"
key: "%secret%"
As you can see, the only difference is switching out http_basic for http_digest. Changing the value of the key property appears to make no difference.
When using an in_memory provider, http_digest works just fine. This matter is only present when using the fos_user_bundle provider.
By working, I mean that with when using http_basic, the valid user credentials are accepted. When using http_digest the same valid user details are not accepted and the browser's default http authentication prompt is re-displayed.
Between security configuration changes, I clear both the dev and prod caches, empty the browser cache and close the browser.
Is there something critical I'm missing from the configuration?
Update
I've logged a successful http_basic attempt and an unsuccessful http_digest attempt and diffed the logs.
Both logs are identical up to and including where Doctrine logs the SQL query used for authentication.
Following the authentication query in the http_digest log are the lines:
security.DEBUG: Expected response: '3460e5c31b09d4e8872650838a0c0f1a' but received: '5debe5d0028f65ae292ffdea2616ac19'; is AuthenticationDao returning clear text passwords? [] []
security.INFO: exception 'Symfony\Component\Security\Core\Exception\BadCredentialsException' with message 'Incorrect response' in /home/jon/www/local.app.simplytestable.com/vendor/symfony/symfony/src/Symfony/Component/Security/Http/Firewall/DigestAuthenticationListener.php:105
Passwords, using the FOSUserBundle, are salted and hashed.
I'd like to ascertain whether this matter arises due a misconfiguration on my part or whether it's a bug in the FOSUserBundle.
HTTP digest authentication works, in short, by comparing hashes calculated from values including the username, realm, password and various nonse and replay-avoidance values.
The plaintext password is required on both the client and server side to generate the same hashes.
FOSUserBundle salts and hashes passwords.
The server-side hash generated within the Symfony\Component\Security\Http\Firewall\DigestAuthenticationListener class will be passed a hashed not plaintext password and so can never generate the correct hash for comparison.
I have two firewalls:
api (for API calls)
main (for everything else)
My client app login happens via the main firewall. However, it does interact with endpoints under the api firewall to fetch data. The problem here is that I don't want to force the user to log in a second time for authenticating against the second firewall.
How can I authenticate against both firewalls with just a single login form?
Perhaps you could try the 'context' firewall property.
Say you have a configuration something like this (which presumably you do):
security:
// providers etc ...
firewall:
main:
pattern: # ...
provider: my_users
http_basic: ~
api:
pattern: # ...
provider: my_users
http_basic: ~
In this case the user's session will contain a '_security_main' property after authenticating against the 'main' firewall, and then when they attempt to access an 'api' location they will be prompted to re-auth and will then gain a '_security_api' session property.
To prevent this re-prompt, you can add the 'context' property to each firewall definition you wish to share the same authentication - so:
security:
# providers etc ...
firewall:
main:
pattern: # ...
provider: my_users
http_basic: ~
context: primary_auth # new
api:
pattern: # ...
provider: my_users
http_basic: ~
context: primary_auth # new
In this case, upon authentication with the 'main' firewall, a '_security_primary_auth' property will be set in the user's session. Any subsequent requests inside the 'api' firewill will then use the value of '_security_primary_auth' to establish authentication status (and so the user will appear authenticated).
Of course this authentication context sharing will work both ways around (whether they auth first with the 'main' or the 'api' firewall) - if you only wanted transience in one direction, things would be more complex.
Hope this helps.