I have weird problem in fresh TYPO3 9.5 and 8.7 installations.
Trying to login into the backend
login with correct username/password, a few secs of load indicator and then the login form is shown again. No login possible.
login with invalid username/password, as expected "Your login attempt did not succeed
Make sure to spell your username and password correctly, including upper/lowercase characters."
There are other problems which are maybe related:
Renaming a file in the File module seems to do nothing, the file itself is renamed. The new name is displayed only after a total refresh of the page.
Deleting log entries. Clicking a log entry deletes it but the list is updated only on refresh
other situations where changes are not reflected in the browser until the page is reloaded.
This happens on MacOS Catalina 10.15.2 / Chrome 79.0.3945.88?
At the same time Firefox seems to work.
Chrome seems to work normally everywhere else.
Found a solution:
Even creating a new news entry did not do anything. The browser console told me:
Mixed Content: The page at 'https://bla.com' was loaded over HTTPS, but requested an insecure resource 'http://bla.com/something'. This request has been blocked; the content must be served over HTTPS.
The site is reachable via https only.
The site was running behind a reverse proxy which proxied all https requests to the real server using http, because proxy-server traffic happens in a DMZ anyways.
TYPO3 seems generate some URLs based on the request url. And the browser complains at mixed (http) reqests that are handled via Javascript.
I modified the proxy config to pass all https requests via https and all is fine.
I had the same error after upgrade to v11. I lost hours to fix it, but finally I found this German forum, and solution was length of ses_id field in table be_sessions. In my case it was 32, and with 190 it works.
"Ich habe die funktionierende Neuinstallation mit der nicht
funktionierenden Update-Version verglichen. Das PHP-Script ist beim
Lesen der Daten aus be_sessions abgebrochen. Das Feld ses_id war
einmal 32 Zeichen lang und einmal 190. Nachdem ich das mit diesem Befehl
geändert habe, ging der Login:
ALTER TABLE be_sessions modify COLUMN ses_id VARCHAR(190) NOT NULL;"
Related
I enabled SLL with the simple SSL plugin on my website https:/www.untwine.eu
All 'sub-sites' and the Wordpress admin pannel are working fine (connection secure). However on my home page there seems to be a problem (attached picture).
I already tried to 'replace all' the http with https.
You seems to have images that goes agains http and not https
check this out
An image with an insecure url of "http://www.untwine.eu/wp-content/uploads/2020/04/background-data-2.jpg" was loaded on line: 828 of https://www.untwine.eu/.
This URL will need to be updated to use a secure URL for your padlock to return.
I have developed an application that allows MSA (Microsoft Account) authentication. I have registered my app here: https://apps.dev.microsoft.com.
When testing my app locally, I can access my app with no problem at my SSL URL of https://localhost:44300, and MSA works fine. When I registered my app, I used https://localhost:44300/signin-microsoft as the Redirect URI.
Problem: I can also access my app at https://127.0.0.1:44300, as one would expect. However, MSA here doesn't work. The error page says, We're unable to complete your request.
Microsoft account is experiencing technical problems. Please try again later. And the URL of the error page reveals that the error is with a mismatch in the Redirect URI: https://login.live.com/err.srf?lc=1033#error=invalid_request&error_description=The+provided+value+for+the+input+parameter+'redirect_uri'+is+not+valid.+The+expected+value+is+'https://login.live.com/oauth20_desktop.srf'+or+a+URL+which+matches+the+redirect+URI+registered+for+this+client+application.
In the Microsoft Apps page, when I try to update the Redirect URI from https://localhost:44300/signin-microsoft to https://127.0.0.1:44300/signin-microsoft, it doesn't allow me to save my change and it shows me this error: Your URL can't contain a query string or invalid special characters, and it provides a 'Learn More' link: https://learn.microsoft.com/en-us/azure/active-directory/active-directory-v2-limitations#restrictions-on-redirect-uris
After reading the info in this link, I see nowhere that a URI like mine (https://127.0.0.1:44300/signin-microsoft) would be an unacceptable URL, as I'm not breaking any of their rules: I have no invalid characters, no query strings, etc.
My research: Looking online, people are getting the Your URL can't contain a query string or invalid special characters because they are actually using a query string or invalid special characters, such as in this link: https://social.msdn.microsoft.com/Forums/en-US/4f638860-ea57-4f0e-85e0-b28e1e357fe2/office-365-app-authorization-redirect-uri-issue?forum=WindowsAzureAD. I couldn't find a case where someone has entered a valid URI and they weren't allowed to save it.
Why I need 127.0.0.1 to work: I need to expose this website, which is running on my local box. In order to have the website running without having an instance of Visual Studio opened all the time, I'm using csrun to host my website in Azure local fabric (by the way, my app is an Azure Cloud Service, with a ASP.NET MVC 5 app as a web role). I followed this instruction for csrun: http://www.bardev.com/2013/03/12/how-to-deploy-application-to-windows-azure-compute-emulator-with-csrun/. Using csrun, it allowed me to host my website in https://127.0.0.1:444 (but, as with https://127.0.0.1:44300, MSA doesn't work). My end goal is to expose this website with a public URL using ngrok (https://www.sitepoint.com/use-ngrok-test-local-site/), so that anyone can access my site.
Therefore, my main question is: how can I have the Redirect URI be https://127.0.0.1:44300/signin-microsoft instead of https://localhost:44300/signin-microsoft?
Make sure you access this portal through https://identity.microsoft.com as this is the only way the steps below will work.
You can get around this error right now by adding the reply URL through the manifest. Login to the portal, select the app you want to configure, and scroll down and hit the Edit Application Manifest button. Then you can add your https://127.0.0.1:44300/ to the replyUrls field.
There's some funny behavior that will only allow this right now if you only register other localhost reply Urls. If this is the only reply URL you need then it shouldn't be a problem.
I've a strange problem, we've got a symfony application that uses google/oauth through HWIOAuthBundle for login, that always works well for every user, our application is worldwide spread, so recently we've got a problem with an specific tld .eg, the rest of the world can authenticate except the egypt.
When someone from Egypt try authenticate, the application redirects to the page login again, I received to status redirect code before that:
302: Moved temporarily
302: Found.
I don't know if is enough information, on my point of view isn't a symfony appllication problem, because is working for the whole world except egypt, and only happens for .net.br in our homolog environment when application is on live using .com.br is working properly included for Egypt.
I have configured 2 providers and used the FOS-Oauth-Bridge. FB works just fine, but when I try connecting to LinkedIn, the browser shows the message
Content Encoding Error
The page you are trying to view cannot be shown because it uses an
invalid or unsupported form of compression.
Please contact the website owners to inform them of this problem.
I tried decoding the generated URL and that seems fine to:
https://www.linkedin.com/uas/oauth2/authorization?response_type=code&client_id=077-dd7c-4815-aea0-8c31e0ce7&scope=r_fullprofile&state=eecd50f81e6ad3e7e23cc11ec50d4768&redirect_uri=http%3A%2F%2Fsf2test.dv%2Fapp_dev.php%2Fsec_area%2Flogin%2Fcheck-linkedin
I tried changing the redirect URL to 127.0.0.1, changing the port to 8X but nothing works
I do not have SSL installed on my Windows / Apache
When I manually change the LinkedIn URL to HTTP (instead of HTTPS), I get this message
Request denied
**Request denied**
Sorry, we are unable to serve your request at this time due to unusual traffic from your network connection.
Reason codes:
3,2,19
Can someone help me figure out the problem?
Migrated a fully-functioning Drupal 7 site and corresponding database to a new server. I am unable to login to the admin side. The error message is: “Access Denied. You are not authorized to access this page.” The username and password has been verified.
I looked at /admin/reports/dblog, the error log shows 2 entries per login. One entry shows the session is opened for the correct username, and the other entry shows access denied and the user is ‘anonymous.’ It is my assumption that Drupal is not able to validate the user so it is assigning the user as anonymous.
I read many forum topics on similar issues. I commented out the ‘$cookie_domain’ in ‘settings.php’, but still nothing. I looked back at the functioning site and saw that 2 cookies are generated: ‘has_js’ and a session ID cookie. In the new site, only the ‘has_js’ cookie is generated (using both Firefox and Chrome browsers). I have verified that the session id is being saved to the session table in the database.
I have looked into modifying ‘php.ini’ (etc/php5/apache2/php.ini) but have not found a solution that saves the session id cookie.
Drupal 7
Linux Server
Ubuntu 12.04
Apache 2.2.22
MySql 14.14
PHP 5.3.10
Uncomment line 340 on settings.php to reflect your domain name
e.g. for localhost
$cookie_domain = 'localhost';
Please note this works for drupal 7 and my php version is 5.6.
Regards,
When migrating drupal installations from server to another there is several problems that could appear.
1) check your file permissions, because sometimes we migrate files from server to another and having different owner:group and this gives serious problems.
2) You need to delete all cache before migrating to avoid having access problems and using wrong urls from cache and so on, in your case you already migrated Drupal, so you need to go to the DB and delete content of all cache_* databases. this could help you.
3) if not you need to look at what php version you have been using and mysql and apache maybe some deprecated functions or so.
I had the same problem, except that I could see the session cookie in Chrome (Settings -> Show Advanced Settings -> Content Settings -> All Site Cookies and Data). The cookie's "Send for" property was set to "Secure Connections Only" and my site was running up on HTTP / port 80. Thus the browser would not send the cookie back to the web.
The problem turned out to be this line in php.ini: session.cookie_secure = 1
When this option is set, PHP will specify that the cookie may only be sent over a secure (HTTPS) connection. This makes it harder to mount a man-in-the-middle attack because the cookie is no longer sent via clear text.
There are two ways to resolve the issue: 1) Switch the site to HTTPS. 2) In php.ini, set session.cookie_secure = 0
I had the same problem. Number 3 from the first answer saved me - I'd recently changed my MAMP PHP version to 5.6 and this seemed to be causing the issue. Reverting back to 5.5 means I can now login.