fixed Blocked loading mixed active content in firefox because of HTTP - javascript

I deployed my react app in netlify and now when I want to login in my app I received
Blocked loading mixed active content
I did a lot search about that and I found out I have to change my request from http to https but now I am not able to do this,is there any other way to address this bug?

Related

Unable to use Google SSO on server react

I am trying to use Google SSO on a server but the popup for Google SSO doesn't display the google accounts to select for logging in. It works when I test it in my local and am able to login too.
I am using the package react-oauth/google
I have added server details in Credentials via Google Cloud Console. Following are URLs in configurations in Authorized JavaScript origins and Authorized redirect URIs:
http://localhost
http://localhost:9998 ## React app is running on this port
http://example.com:9998 ## Server url can be accessed using domain and port
I am getting 403 error when following url is called https://accounts.google.com/gsi/button:
Following is the error that is shown in cosole
[GSI_LOGGER]: The given origin is not allowed for the given client
Tried clearing cache and hard reload. It doesn't work either.
Does it have something to do with using ports along with domain name?
EDIT: I have also tried creating new credentials.. but that doesn't work either
I had the same issue at work. Does your website have ssl certificate? If not try adding ssl certicate (otherwise google sso won't work without it) and then change the urls in the Authorized JavaScript origins and Authorized redirect URIs with the https url. This should fix the issue. Let me know if it worked :)

JS service-worker and cache storage API with http 302 - how to cache the redirect?

I have a webpage, serverd via https from Tomcat, with serviceworker according to examples for fetching a resource and store it in the cache. If Tomcat is not running, the page is served from the cache storage - so far so good.
My Tomcat configuration contains the redirectPort attribute to redirect http to https. The problem I have: When Tomcat is not running and my webpage is accessed via http, browser shows: Connection refused since the http 302 redirect is not stored in the cache. How I could achieve that?
Unfortunately service workers require https for safety, so you cannot have a service worker intercept an http request.
If you would like to force browsers to visit your page in https you could enable HSTS:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security
The HSTS list can be preloaded in the browser allowing it to work offline. Note, however, you need to be careful when enabling HSTS as if you make a mistake it can be difficult to correct.
Alternatively browsers are slowly moving towards loading https by default unless the user explicitly types http. For example:
https://blog.chromium.org/2021/03/a-safer-default-for-navigation-https.html

Login with facebook on localhost without https

I am trying to implement login with facebook on my website.
I configured app id and URL everything properly.
Problem is I am running on HTTP as I am on localhost.
When I try to log in it gives me this error
Insecure Login Blocked: You can't get an access token or log in to this app from an insecure page. Try re-loading the page as https://
I have checked many answers on StackOverflow but seems like those are a very old answer and things have changed now.
Can anyone tell me if its possible to login without https on localhost?

Using the Azure Mobile Apps JavaScript Client in browser to access Authenticated Tables

I am following the tutorial for azure mobile app services here.
The authentication works fine when using Cordova azure client. However, on the browser, I get the error below in chrome console:
XMLHttpRequest cannot load http://MYAPP.azurewebsites.net/tables/Users?.
The request was redirected to 'https://MYAPP.azurewebsites.net/tables/Users?',
which is disallowed for cross-origin requests that require preflight.
A workaround is to run chrome with --disable-web-security flag. However, I wonder if there is a way to fix this issue.
I have set CORS in azure portal to * which I assume allows all origins
You need to configure the CORS settings in the portal to allow the domain of the host that the web server is hosted on. For example, if you're entering something like https://www.mywebsite.com/ into the address bar to hit your Mobile App, you need to add www.mywebsite.com into the CORS settings.
I also notice the request is being redirected from http to https. Azure requires https for any authenticated requests (to protect the JWT token from man in the middle attacks) and will redirect if the request is on http. You need to change the URL in the constructor for your Mobile Apps client to use HTTPS.

Prevent blocking of redirect from https to http in service worker

I have been working on implementing a service worker to add some caching benefits to our site and all has been going well apart from one particular page on the site.
This page is linked to as https://domain/path but a server side redirect looks to redirect this to http://domain/path/ and this point the service worker is blocking the request. When the link is clicked the page puts out a This webpage is not available error and the console shows the following:
Mixed Content: The page at 'https://domain.com/service-worker.js' was loaded over HTTPS, but requested an insecure resource 'http://domain.com/path/'. This request has been blocked; the content must be served over HTTPS.
Ideally we will be looking to ensure that redirect stays on https, but while that issue is resolved is there a way of working around this within the service worker?
In Chrome, current implementation prevents the SW to mix content. Chrome explain why at: https://code.google.com/p/chromium/issues/detail?id=448672#c4 stating:
So every request using fetch() must be blocked, because fetch is not an optionally-blockable request context.
However, I raised the question to the specification committee as it seems to be against the current specification. You can follow the discussion and read the rationale behind at: https://github.com/slightlyoff/ServiceWorker/issues/813

Categories