I've created a registration system like this:
User fills in a form at /register
The form is posted to the same page (/register)
If the form is valid, the user will be added to the database with isActive = 0
A token will be generated to activate the user
The user gets an e-mail with a link containing the token
The user clicks the link and goes to /activate/{token}
If the token matches to the database, the user will be activated isActive = 1 and redirected to return $this->redirect($this->generateUrl('login')); with a flashmessage Account activated, you can login now.
Everything is working fine, over 1500 users registered in the past 2 days. But some are experiencing trouble activating their account. After clicking the link they receive a 404-error. However, their accounts are activated as supposed.
I searched the logs and found around 1500 records, more or less around the time users are activating their account: No route found for "GET /favicon.ico"
/favicon.ico doesn't exist, the favicon is located somewhere else and included in shell.html.twig, so every regular page has the favicon. But because the /activate/{token} is just redirecting, no view is loaded.
It possible this has something to do with the error some users are encoutering?
Maybe the error has nothing to do with the favicon, all suggestion are more then welcome. I'm not able to reproduce the error, so it's very hard to debug at the moment.
Also try to use different browsers to test this. You can also test this on your local machine. I have found online that some browsers (IE) automatically request /favicon.ico in some cases, if you include it somewhere or not.
Read through this for a start: How to prevent favicon.ico requests?
I see this is an old thread and you probably solved your issue years ago but here are my two cents - when I try to run a Symfony 2.3 application with one of the later php 5 versions, I get the same error message as you in my log file, it complains about the favicon.
That is however not the real issue. The real issue that caused this redirection and in turn the favicon-issue is that I am using an old version of FOS User Bundle, and there is a conflict between the user unserialization and the new php version. Move to a more recent version of FOS User Bundle and you should be ok.
Related
I am new to firebase and wanted to update the Authorized domains(was able to add domains a few weeks ago) for the authentication, but I am unable to delete or modify the domains. The website throw an "Error updating authorized domain list" error. Am I missing something?
I had same issue with the result that for any reasons one of the already listet domain was entered with https://.This produces an error. When you add a new url the old one in the list get send also with the request (look in dev console of your browser). If there are invalid values you get an error of invalid parameters (look also in dev console of your browser) but the user interface just say "error".
Its a little bit weird, maybe some month ago an entry with https:// was possible.
I had to delete the entry https://mydomain.de, after that I was able to replace it with mydomain.de without and also any other new domain.
For sure just one possible reason of problems with whitelisting, but maybe it helps someone.
I was having the same issue (using Chrome). I noticed it worked for Krueger
in Safari. I just opened up the Firebase authentication settings in Edge and had no problem adding a domain!
I'm working on a WordPress website: https://samarazakaz.ru/
The client discovered a strange bug. After newly opening a browser the first login always fails, second one succeeds.
I tracked down the issue to a strange cookie with the name RCPC that is being set when the login form is submitted. If the cookie is missing then the login fails regardless of proper credentials.
I searched high and wide for any information about this cookie but could not find anything useful. The only thing remotely resembling my case was on some discussion on a site called https://codeforces.com/ . But nothing on that mentioned anything related to WordPress.
The site has a bare-bones setup with Elementor and my own plugin. And nothing in my code messes with cookies or the login process. I downloaded all website files and search in all files for "RCPC" but found nothing.
The site is behind an Nginx proxy, but I could not find any connection with this cookie and Nginx either.
I noticed that the value of this cookie is constant. So, as a workaround I jerry-rigged my plugin to set this cookie any time when it's not set. But, of course, I'm not very happy with that solution because I don't know if this will just stop working one day.
Update:
I verified that this is coming from the hosting. I renamed the /wp-login.php file and made a request to it, and it didn't return a 404 error but a 200 page with the same redirect code and the header to set the cookie. The hosting is reg.ru .
As far as I can figure this is a counter measure against automated password guessing. Any request (POST, GET, etc) to the /wp-login.php will get the redirect script with the cookie setting header. Only requests containing the correct RCPC cookie will get forwarded.
Upon further testing found that the value of the RCPC cookie is some kind of hash generated from the request's IP address. Because all of our computers got the same one but from other locations its different.
This does not cause any problem if the standard WordPress login form is used because that lives at the /wp-login.php address, so the first GET request will generate the cookie. However, we had a custom login page which didn't access /wp-login.php until the form was submitted.
Based on these discoveries I made a workaround, which is simply adding a one line JS script to the login page which makes a (fetch) request to the /wp-login.php page and simply discards the result. This is enough to set the cookie in the browser so that the form will work at the first try.
Need on hosting disable test-cookie-module
After the transfer of the site to a new hosting, there is a problem: the site produces an event redirect to the old hosting. Currently set up nginx on something that would have sent data to pure servers but it produces still a redirect. The redirect itself is made starting from the app file.php to HttpKernel.php in handler (......) there is a call to events, $this->dispatcher - >dispatch(.................) which forms a redirect and does not let on, if you remove this element, then the page is formed only without data from the database and there is an error 404 page not found. When the page loads, a kernel event is generated.request and security.authentication.success and with such parameters it produces a redirect.
Check for kernel request events. You may have a hardcode somewhere. I dont know much about your symfony version, but you can debug events with php bin/console debug:event-dispatcher kernel.exception. After you do this post code here we might be able to help. AND YES question is formed very poorly.
we have an odd situation where a user logs into the site (Asp.Net), and upon logging out, it only directs us to the main page "https://newsite/default.aspx" however if we replace default with login, we are immediately logged back in. This happens only when we go through the public IP with associated DNS A record located on the F5. If we open the site on the IIS server via IP binding "https://ipaddress/default", I can login and logout and stay logged out, it works as expected. I have worked with F5 support and have tried multiple different configuration changes, and no dice, same behavior everytime. The newsite is set up identically in F5 to our current production site, and developers say the logout code is identical to current production so we are confused as to why this is happening. Persistence is set on the load balancer as well. Any help in the right direction would awesome.
A couple things I would suggest checking:
If you monitor the traffic with something like Fiddler and compare the results of login/logout with the F5 and without, do you see any difference? I would look for specific things like cookies being set or removed. I know ASP.NET uses specific cookies for sessions, so I would wonder if that cookie is not getting deleted properly on logout.
Once you log out of the site (when going through the F5), if you refresh the page, do you stay logged in (in this case, I could see where some kind of caching may send back the page even though you're logged out. If this is the case, you could have an F5 admin check to see if there's a Web Acceleration profile on the virtual server and remove it to see if that helps.
Looks like specific security cookie code was causing the issue of creating a duplicate cookie within ektron.
Following code was removed, and now log out is working properly via SSL through our F5.
Code removed:
Dim lSec As SecurityAPI.Cookie = New SecurityAPI.Cookie(Me, mServerEnvironment, mCOGUser.PeopleID)
lSec.SetCookie()
In my Drupal installation I often need to login 2 times to get logged in.
This is the case when I go exactly this way:
open a new incognito window in browser (in my case Chrome)
try to login -> login failed with no message
try to login 2nd time -> logged in
close the window WITHOUT logout
open a new incognito window in browser and try to login -> login failed
When I logout and try to re-login, the login works.
There are some more randomly cases where the login doesn't work too at the first time. But these cases I can't describe exactly.
In Drupal log and Apache log I don't get any message after a failed login.
Where can I start my search to solve this? Or does anyone had the same problem?
The session cookies are stored by drupal to confirm users as being logged in. Check the developer tools in chrome to asses whether a cookie has been or was meant to be stored. Icognito Mode makes a point of treating cookies with deference (might also be the general settings of your browser).
Try setting your cookie domain settings.php. Depending on your hosting or setup this sometimes needs to be done to make sure cookies are working correctly.
Basically you will add a line like
$cookie_domain = '.my_site.com';
Do not add a trailing slash and do not remove the leading period (this is documented and commented out in settings.php, do a find for $cookie_domain and you should see it.
https://drupal.org/node/1844574