I created a webapp from the Symfony4 Demo app, including the Login system and multi-language support.
All worked perfectly with the Built-in Apache server in the port 8000.
- When I configured a Xamp apache I needed to generate the '.htaccess' file in the 'public' folder in order to make the website working(composer require symfony/apache-pack), but finally it worked.
- Now I deployed the app in a mutualized hosting server, and configured the .env properly, queries to the DB work, but I'm not able to login to the webapp.
Do you from where can be the problem?
Thx for your help!
[2019-09-05 11:05:38] request.INFO: Matched route "security_login".
{"route":"security_login","route_parameters":{"_route":"security_login","_controller":"App\Controller\SecurityController::login","_locale":"en"},"request_uri":"http://xxx.xxxx.com/en/login","method":"GET"}
[] [2019-09-05 11:05:38] security.INFO: Populated the TokenStorage
with an anonymous Token. [] [] [2019-09-05 11:05:39] request.INFO:
Matched route "_wdt".
{"route":"_wdt","route_parameters":{"_route":"_wdt","_controller":"web_profiler.controller.profiler::toolbarAction","token":"984d25"},"request_uri":"http://xxx.xxxx.com/_wdt/984d25","method":"GET"}
[] [2019-09-05 11:05:43] request.INFO: Matched route "security_login".
{"route":"security_login","route_parameters":{"_route":"security_login","_controller":"App\Controller\SecurityController::login","_locale":"en"},"request_uri":"http://xxx.xxxx.com/en/login","method":"POST"}
[] [2019-09-05 11:05:43] doctrine.DEBUG: SELECT t0.id AS id_1,
t0.full_name AS full_name_2, t0.username AS username_3, t0.email AS
email_4, t0.password AS password_5, t0.roles AS roles_6 FROM xxx_user
t0 WHERE t0.username = ? LIMIT 1 ["pierre_admin"] [] [2019-09-05
11:05:43] security.INFO: Authentication request failed.
{"exception":"[object]
(Symfony\Component\Security\Core\Exception\BadCredentialsException(code:
0): Bad credentials. at
/home/xxxxcom/xxxx.com/xxx_xxxx_com/vendor/symfony/security-core/Authentication/Provider/UserAuthenticationProvider.php:85,
Symfony\Component\Security\Core\Exception\BadCredentialsException(code:
0): The presented password is invalid. at
/home/xxxxcom/xxxx.com/xxx_xxxx_com/vendor/symfony/security-core/Authentication/Provider/DaoAuthenticationProvider.php:58)"}
[] [2019-09-05 11:05:43] security.DEBUG: Authentication failure,
redirect triggered. {"failure_path":"security_login"} [] [2019-09-05
11:05:43] request.INFO: Matched route "security_login".
{"route":"security_login","route_parameters":{"_route":"security_login","_controller":"App\Controller\SecurityController::login","_locale":"en"},"request_uri":"http://xxx.xxxx.com/en/login","method":"GET"}
[] [2019-09-05 11:05:43] security.INFO: Populated the TokenStorage
with an anonymous Token. [] [] [2019-09-05 11:05:43] request.INFO:
Matched route "_wdt".
{"route":"_wdt","route_parameters":{"_route":"_wdt","_controller":"web_profiler.controller.profiler::toolbarAction","token":"47fb65"},"request_uri":"http://xxx.xxxx.com/_wdt/47fb65","method":"GET"}
[]
Simple answer ;)
- Php 7.1 not working with Symfony4
- Move to 7.2 works fine
Related
Trying to send cookie back after login request on my hobby project website. For some reason it is working when running locally i.e. http://localhost:3000. But as soon as I push my API online and try to access it through my live website, I see no cookie under Application -> Cookies -> website (using chrome). I have googled a lot and I believe I have set check off every CORS policy.
The nodeJS is running in AWS lambda and is invoked through API gateway. API GW is directed to through a cloudfront distribution (if it matters).
In my express backend I have logged my headers accordingly:
res.cookie('jwt', token, cookieOptions);
console.log('Checking cookie', res);
console.log('Checking cookie', res.cookies);
res.status(statusCode).json({
status: 'success',
data: {
user
}
});
The output of this is partially this:
'access-control-allow-origin': [ 'Access-Control-Allow-Origin', 'https://example.com' ],
vary: [ 'Vary', 'Origin' ],
'access-control-allow-credentials': [ 'Access-Control-Allow-Credentials', 'true' ],
'access-control-allow-methods':
[ 'Access-Control-Allow-Methods',
'GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS' ],
'access-control-allow-headers':
[ 'Access-Control-Allow-Headers',
'Origin, X-Requested-With, Content-Type, Accept, X-PINGOTHER' ],
'x-ratelimit-limit': [ 'X-RateLimit-Limit', 100 ],
'x-ratelimit-remaining': [ 'X-RateLimit-Remaining', 97 ],
date: [ 'Date', 'Fri, 11 Dec 2020 23:20:28 GMT' ],
'x-ratelimit-reset': [ 'X-RateLimit-Reset', 1607732145 ],
quizappuserloggedin: [ 'QuizAppUserLoggedIn', 'false' ],
'set-cookie':
[ 'Set-Cookie', 'my-cookie'; Path=/; Expires=Sat, 12 Dec 2020 23:20:34 GMT; HttpOnly; Secure'
From what I can tell I have set my CORS settings correctly. From my frontend I have set:
axios.defaults.withCredentials = true;
From what I can tell I have done everything I can find in Set cookies for cross origin requests
Meaning I have doubled checked my cors settings and from the print statement it looks like the cookie is being sent. But why is the browser not picking it up?
Could post the actual site and github repo if it helps, I have been stuck here for a whole now.
UPDATE
I looked at the response headers in my browser and compared it against the headers in the backend api. From that comparison I can see that my "set-cookie" header isn't included in the response even though I can clearly see that it is included in the response from the backend:
UPDATE 2
I believe after further investigation that I have narrowed it down to being an CORS issue with AWS API Gateway. I looked into these, but still no luck.
How to add CORS header to AWS API Gateway response with lambda proxy integration activate
Amazon API gateway ignores set-cookie
Logs from the lambda cloudwatch right before the response is being sent by the express framework as well as cloudwatch logs from the API Gateway (response headers).
API GW cloudwatch logs of the response headers:
Lambda cloudwatch logs of the response object sent by express framework:
Turns out it wasn’t a CORS issue. I had simply forgotten to forward cookies from my cloudfront distribution.
I have Keycloak and Keycloak-Gatekeeper set up in OpenShift and it's acting as a proxy for an application that is running.
The application that Keycloak Gatekeeper is proxying requires a custom cookie to be set so I figured I could use the Gatekeeper's custom header configuration to set this however I'm running into issues.
Configuration looks like:
discovery-url: https://keycloak-url.com/auth/realms/MyRealm
client-id: MyClient
client-secret: MyClientSecret
cookie-access-name: my.token
encryption_key: MY_KEY
listen: :3000
redirection-url: https://gatekeeper-url.com
upstream-url: https://app-url.com
verbose: true
resources:
- uri: /home/*
roles:
- MyClient:general-access
headers:
Set-Cookie: isLoggedIn=true
After re-deploying and running through the auth flow, the upstream URL/application is not receiving the custom header. I tried with multiple headers (key/value) but can't seem to get it working or find where that header is being injected in the flow.
I've also checked logs and haven't been able to find anything super useful.
Sample Gatekeeper Config
Gatekeeper Custom Headers Docs
Any suggestions/ideas on how to get this working?
remove Set-Cookie.
Simply add
headers:
isLoggedIn: true
I'm try to integrate Zabbix UI with Keycloak SSO, using keycloak-proxy.
My setup is the following:
Nginx is the entry point: it handles the "virtual host", forwarding the requests to keycloak-proxy.
Keyclock-proxy is configured with client_id, client_secret, etc. to authenticate the users to Keycloak;
Zabbix dashboard on Apache, default setup: I enable the HTTP authentication.
I've created a test user both in Keycloak and Zabbix.
The authentication flow is ok: I'm redirected to KeyCloak, I do the authentication, but I always get "Login name or password is incorrect." from Zabbix UI.
What am I doing wrong?
Has anyone tried to use OIDC authentication with Zabbix?
I'm using Zabbix 4.0, KeyCloak 4.4, Keycloak-proxy 2.3.0.
keycloak-proxy configuration:
client-id: zabbix-client
client-secret: <secret>
discovery-url: http://keycloak.my.domain:8080/auth/realms/myrealm
enable-default-deny: true
enable-logout-redirect: true
enable-logging: true
encryption_key: <secret>
listen: 127.0.0.1:10080
redirection-url: http://testbed-zabbix.my.domain
upstream-url: http://a.b.c.d:80/zabbix
secure-cookie: false
enable-authorization-header: true
resources:
- uri: /*
roles:
- zabbix
Zabbix expects PHP_AUTH_USER (or REMOTE_USER or AUTH_USER) header with the username, but keycloak-proxy doesn't provide it. Let's use email as a username (you can use any claim from the access token in theory). Add email to the request header in the keycloak-proxy config:
add-claims:
- email
And create PHP_AUTH_USER variable from email header in the Zabbix Apache config:
SetEnvIfNoCase X-Auth-Email "(.*)" PHP_AUTH_USER=$1
Note: Conf syntax can be incorrect because it is off the top of my head - it may need some tweaks.
BTW: there is a (hackish) user patch available - https://support.zabbix.com/browse/ZBXNEXT-4640, but keycloak-gatekeeper is a better solution
For the record: keycloak-proxy = keycloak-gatekeeper (the project was renamed and migrated to keycloak org recently)
I am trying to use AD authentication. I am able to login successfully but i am not authorized to perform any query in marvel.
Everytime i execute query in marvel, i get the following error.Below are the details
{
"error": "AuthorizationException[action [indices:data/read/search] is unauthorized for user [shivang.Mittal]]",
"status": 403
}
elasticsearch.yml (C:\ES\elasticsearch-1.4.4\config)
shield:
authc:
realms:
active_directory:
type: active_directory
domain_name: tavant.in
url: "LDAP://DODC1.tavant.in:389"
user_dn_templates:
- "cn={0}, dc=tavant, dc=in"
group_search:
base_dn: "dc=tavant,dc=in"
files:
role_mapping: "C:/ES/elasticsearch-1.4.4/config/shield/role_mapping.yml"
role_mapping.yml (C:\ES\elasticsearch-1.4.4\config\shield).
Copied the same file in Node(C:\ES\elasticsearch-1.4.4\data\elasticsearch\nodes\0)
admin:
- "cn=users, dc=tavant,dc=in"
roles.yml
admin:
cluster: all
indices:
'*': all
UPDATE
As per Jaymode suggestion, I added the shield.auth: debug.
Below is the log (Which i thought would be useful)
[2015-04-27 11:54:12][DEBUG][shield.authc.ldap.support] [Talisman] the roles [[]], are mapped from these [active_directory] groups [[CN=Users,CN=Builtin,DC=tavant,DC=in, CN=Domain Users,CN=Users,DC=tavant,DC=in,
[2015-04-27 11:54:14,935][DEBUG][shield.authc.activedirectory] [Talisman] authenticated user [shivang.Mittal], with roles [[]]
[2015-04-27 11:54:16,447][ERROR][marvel.agent.exporter ] [Talisman] error adding the marvel template to [[0:0:0:0:0:0:0:0]:9200] response code [401 Unauthorized]. content: [{"error":"AuthenticationException[missing authentication token for REST request [/_template/marvel]]","status":401}]
[2015-04-27 11:54:16,447][ERROR][marvel.agent.exporter ] [Talisman] failed to verify/upload the marvel template to [[0:0:0:0:0:0:0:0]:9200]:
Server returned HTTP response code: 401 for URL: http://[0:0:0:0:0:0:0:0]:9200/_template/marvel
[2015-04-27 11:54:16,447][ERROR][marvel.agent.exporter ] [Talisman] failed to verify/upload the marvel template to [[0:0:0:0:0:0:0:0]:9200]:
Server returned HTTP response code: 401 for URL: http://[0:0:0:0:0:0:0:0]:9200/_template/marvel
EDIT 2: Based on your log message, you probably want to use the following mapping
admin:
- "CN=Users,CN=Builtin,DC=tavant,DC=in"
EDIT: I think I see your issue. In your role_mapping.yml you have:
admin:
- "cn=users, dc=tavant,dc=tavant"
It should most likely be:
admin:
- "cn=users,dc=tavant,dc=in"
I wonder if the DN you are using for role mapping is correct and is being retrieved. If you set debug logging the list of groups that are found for the user will be logged. To enable debug logging, edit the C:\ES\elasticsearch-1.4.4\config\logging.yml file:
...
logger:
# Add the line below
shield.authc: DEBUG
...
The log line will look something like this: the roles [], are mapped from these [active_directory] groups [ list of group DNs here ] for realm [active_directory/active_directory]
In that line you will find the actual list of group DNs that are retrieved. Also, your realm configuration can be simplified to the following:
shield:
authc:
realms:
active_directory:
type: active_directory
domain_name: tavant.in
url: "LDAP://DODC1.tavant.in:389"
The other settings actually appear to just specify what would be the default values if they are not specified.
I have a Symfony 2 app using the basic in_memory authentication (as described in the security documentation). The login works fine in our development environment(s). But on the staging server, the basic authentication doesn't seem to provide a proper token -as seen in the hereby provided logfile-; thus we keep on getting the login popup again and again.
Our security configuration:
security:
firewalls:
secured_area:
pattern: ^/
anonymous: ~
http_basic:
realm: "Secured Demo Area"
access_control:
- { path: ^/admin, roles: [ROLE_ADMIN]}
providers:
in_memory:
users:
admin: { password: admin, roles: 'ROLE_ADMIN' }
encoders:
Symfony\Component\Security\Core\User\User: plaintext
This is the log output from the (successful) development environment login:
[2011-07-21 13:49:48] security.DEBUG: Read SecurityContext from the session [] []
[2011-07-21 13:49:48] security.DEBUG: Reloading user from user provider. [] []
[2011-07-21 13:49:48] security.DEBUG: Username "root" was reloaded from user provider. [] []
And this is the log output from the staging environment login:
[2011-07-21 13:53:08] security.INFO: Populated SecurityContext with an anonymous Token [] []
[2011-07-21 13:53:08] security.DEBUG: Access denied (user is not fully authenticated); redirecting to authentication entry point [] []
[2011-07-21 13:53:08] security.DEBUG: Calling Authentication entry point [] []
Thanks in advance for the help.
Your dev environment is probably running PHP as mod_php while your staging server is probably running it as FastCGI. By default, the PHP_AUTH_USER and PHP_AUTH_PW server variables are not filled in this context when you authenticate via HTTP basic, and these are what Symfony is using to create the Security context and validate your password.
If you're running this as FCGI on Apache you can fix this. One is to force FastCGI to pass the Authorization header, which it normally suppresses. Add this to the Apache site definition next to the other FastCGI configuration options:
FcgidPassHeader Authorization
For other applications you may also need to mess around to a greater degree (as described here) but for Symfony just passing the header should be sufficient.