So, all my routings looks like this
login: /studio/{uuid}/login
logout: /studio/uuid/logout
programs: /studio/{uuid}/programs
levels: /studio/{uuid}
and everytime I access the link via {{ url('login|orwhathever') }} I have to pass uuid. Because all my links will contain uuid I would like to automatize that.
Of course, previously I did not have uuid in the URL and it was just stored in the session if I needed it. But I recently noticed a problem when session expires it supposed to generate login url but it contains uuid parameter and because this parameter is NULL it will throw an error.
So either it must be fixed by providing {uuid} to each url or
somehow pass uuid to Symfony logout method in security.yml
frontoffice_area:
pattern: ^/
anonymous: ~
simple_form:
authenticator: security.user_authenticator
login_path: login #this needs uuid from somewhere
check_path: validate
Related
The isssue I am trying to address is to automatically redirect my application to the user entered url after login. Since I have a centralized authentication server I cant user 'HTTP_REFERER' as it always returns null when am being transferred to the authentication server.
My solution is to use the security.yml in my application server to pass the redirection url as url parameter. I have implemented that as follows,
parameters.php
$container->setParameter('referer', $_SERVER['REQUEST_URI']);
security.yml
secured_area:
pattern: ^/
stateless: true
form_login:
login_path: %accounts_host%/signin?referer=%referer%
simple_preauth:
authenticator: app.security.authenticator
But my issue is that the referer parameter in security.yml is always static. It always gives the first application url I type in. Lets say if i type www.appserver.com/product/1, the next time if I type in www.appserver.com/product/200 the referer will always return www.appserver.com/product/1 in the authenitcation server.
However, If I do a print_r($_SERVER['REQUEST_URI']); exit(); in the parameters.php the value changes for my each request.
I was at this for quite some time and I am very lost at this point. Any help on getting this referer value dynamically on the security.yml would be really appreciated. thanks :)
One of three things caused this and I am not sure which of the 3 it was. So I will mention all 3 in the hope it will help others save time.
Initially I changed database user credentials within parameters.yml
This wasn't working as the user in question couldn't log in from localhost. That said, I used the site to test the connection, which might have upset the cookie.
I had some cache folder permissions issues due to a missing image. So I had to clear the cache and adjust some permissions as you do every time.
Finally, I changed the paths for security.yml
form_login:
login_path: /login
check_path: /login_check
logout:
path: /logout
to:
form_login:
login_path: /account/login
check_path: /account/login_check
logout:
path: /account/logout
Along with the appropriate changes in routing.yml
The result was that my already logged in user not longer passed security credentials and if I tried to login in via a different user/browser, I was always faced with:
"Your session has timed out or you have disabled cookies"
Many many hours were spent following red herrings, checking security, login handling, redis etc.
Answer below.
I ultimately found the answer here:
Symfony authentication - can't get past login page in production (The answer by pleerock)
But wanted to link the error message in my subject line with this solution below:
security:
firewalls:
main:
form_login:
require_previous_session: false
This fixed the issue for browsers which hadn't been logged in prior to the problem.
For my browser which had already been logged in, I had to manually delete the session cookie to get things working again.
I think Adi's answer is not a solution, just work around.
i did realise
in config.yml there is cookie_domain parameter;
session:
save_path: ~
cookie_domain: %cookie_domain%
if you use a custom domain like test.myapp you should set here the same. When these both do not match this problem occurs.
It should appear as below;
cookie_domain: 'test.myapp'
your actual domain: test.myapp
i hope this helps you.
I am working on symfony 2.3 project having the following routing code
just2_frontend_logincheck:
pattern: /login_check
It doesn't have
defaults:{ _controller: testBundle:User:login }
But it is working. But I don't know how the routing is working. Is it possible? Please advice me about the routing.
The check_path route/path is used by your firewall to catch login requests.
This route's action is never really accessed. It's the route/url your login form posts to and the request should be processed by your firewall's provider service.
If the check_path route's action is being executed there is something wrong with the firewall (the request is not processed by your firewall).
As you can see here FOSUserBundle"s check_path is routed to SecurityController::checkAction and just throws a RuntimeException.
The configuration of the check_path can be found in app/config/security.yml under security.firewalls.<firewallname>.form_login.check_path.
It can either be a pattern like /login_check or as in your case a route name i.e. just2_frontend_logincheck but there is no underlying action.
security:
providers:
your_provider_name: your_provider_service # authentication provider
# ...
firewalls: # Required
your_firewall_name:
# ...
provider: your_provider_name
form_login:
check_path: /login_check # submit the login form here
# in your case a route name:
# just2_frontend_logincheck
Under the hood symfony calls the authenticate() method of the service your_provider_service to check the credentials provided.
You can find the class used as the provider-service using:
app/console debug:container --show-private your_provider_service
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.