would you please tell me what i did wrong with my service worker installation, i have those errors appear in chrome console (see the image-1).
The script resource is behind a redirect, which is disallowed. service-worker.js:1
Failed to load resource: net::ERR_UNSAFE_REDIRECT https://harampress.com/post/45/service-worker.js
i use Laravel framework in backend if that could help
just to know that my service-worker.js is in the root of the website, works fine on home page no errors on chrome console, but the moment i try to navigate to a post for example, those two errors appears (see image-2).
knowing that i use sw-precache and sw-toolbox, i generate the service worker useing sw-precache with gulp.
image-1
image-2
see the solutions here on github discussion
the message from the discussion in github that actually answered to my problem :
What #wanderview means is that when you do
navigator.serviceWorker.register('/sw.js')
The actual requesting URL is the sw.js located in the root
but when you do
navigator.serviceWorker.register('sw.js')
This is actually a Relative URL so what you actually request might be /post/blah/sw.js and your server might treat it as 404 and do some redirect.
Related
I have a golang API app that is currently serving double-duty as a Single Page App server with static content using the method shown here: https://hackandsla.sh/posts/2021-11-06-serve-spa-from-go/
Everything is working great in terms of navigation until users try to refresh URIs with encoded JSON in them. For example:
/licenses
will refresh file and draw the page as it would normally have appeared through internal history.push()
/licenses/show/%7B"options":%7B"container":"home","field":"date","order":"desc"%7D,"license":"00001a"%7D
will cause the 500 error.
I did the initial development with IIS as a web server so these Refresh errors never happened in that environment. And when the server is ready to be deployed I plan to use Caddy and reverse proxy the API and am assuming it will handle the Refreshes with the same aplomb as IIS.
But for now I am hoping to run tests against my simple server so I'd like to solve this issue out of curiosity in addition to development expediency.
Bottom line: What cause golang http.ListenAndServe to return 500 errors?
UPDATE:
As I need to be able to test and hand off for others I have converted to a querystring which http.ListenAndServe is happy with:
/licenses/show/%7B"options":%7B"container":"home","field":"date","order":"desc"%7D,"license":"00001a"%7D
causes 500 error
/licenses/show?state=%7B"options":%7B"container":"home","field":"date","order":"desc"%7D,"license":"00001a"%7D
works fine
Firefox seems to fail on registering a ServiceWorker for Push Notifications, with an error "InvalidStateError: An attempt was made to use an object that is not, or is no longer, usable", but the code works in Chrome and Edge, and appears to be compliant with the examples online and the spec.
I've thrown an example up on one of my test sites, https://wiegandtech.net/ - visiting it in Chrome will prompt for permission and then opt-in successfully, sending the info to the server. But Firefox prompts, doesn't complete the registration, and doesn't fire any error or throw anything into the console. When I try to debug, it seems to never return from navigator.serviceWorker.ready.then call - I debug in and reg is undefined, even though the promise says it shouldn't be. I can find no reason why this is failing. I do see in Fiddler that FF gets the worker file, so it appears to be starting the call, but never finishing? The worker is valid JavaScript, as far as I can tell. Does anyone have any documentation on how Firefox's implementation is different from Chrome's/the spec?
Firefox requires the ServiceWorker's URL to end in .js - I was using an ASP.Net site and returning javascript but through my own controller. When I just give it the URL for the .js file itself, it now works. Would file a bug, but too non-trivial to setup a site given that ServiceWorkers require a real life site to troubleshoot, and their source code doesn't appear to be on github.
I am running a WordPress on an Azure Web app connecting to a MySQL server on a different Windows server. When loading the mentioned page in Chrome, it shows 2 popups 403 & Forbidden. Checking the console throws this error - ecbcc.js:2 POST /wp-admin/admin-ajax.php 403 (Forbidden)
This works fine on FireFox & IE but not on Chrome. Any ideas why?
This is because of your cache. Minified version of JS is causing the issue in chrome browser. Check or purge the cache and check for the permissions applied to cached files as well.
I faced the same issue but it took a long time for me to fix it. Because my solution was not caused by common things like cache, .htaccess, files permissions, etc. I apply all the possible solutions as described here. When nothing worked for me, then I talked with my hosting provider and the issue was on their side. Actually, the server has black-listed my IP.
Below is the reply from the support of my hosting provider:
After checking it, it looks like the issue is caused by trigger
ModSecurity rules.
ModSecurity is an Apache module that works as a web application
firewall. It blocks known exploits and provides protection from a
range of attacks against web applications. However, sometimes,
mod_security may incorrectly determine that a certain request is
malicious, while it is actually legitimate. In such a situation, we
can whitelist the triggered mod_security rule on the server, so that
you can bypass the block.
In order to properly investigate, we need you to share your IP address
with us. You can copy it from here: https://ip.web-hosting.com/
Looking forward to your response.
This error can appear for more than one reason. Except for the accepted answer, if you are using a shared hosting solution as a server then it would be best to contact the support of the service. Also if you use Plesk or Cpanel you can check the server logs to see if there is any false positive rule that from mod_security that catches the error. Then you can find the error that could look something like that:
ModSecurity: Warning. Match of "test file" against "REQUEST_FILENAME" required. [file "/etc/httpd/conf/modsecurity.d/rules/custom/006_i360_4_custom.conf"] [line "264"] [id "77140992"]
You can apply the ID on your firewall exclusion list (if this is provided by your hosting service) and then the server will not block the request anymore.
IMPORTANT: If you are not sure what you are doing, ask your hosting provider for support. Experimenting on live servers/sites is not the best option and I would strongly recommend avoiding it.
I'm developing an offline Android app with Genexus Ev3 U9 and when I try the app in the device I see there is no initial synchronization, even when I try to execute a manual sync the app shuts down. The cat log shows that request made to URLs like http://192.168.12.17/MyAppSmartDevicesEnvironment/gxmetadata/MyApp.android.json
worked fine but when the app tries to get this URL http://192.168.12.17/MyAppSmartDevicesEnvironment/rest/MyAppOfflineDatabase?fmt=json&event=gxchecksync returns 404 I tried the same link in my laptop and it's like the requested resource was not created by GeneXus.
What could be wrong?
There are actually a couple of things you might want to check.
When you accessed http://192.168.12.17/MyAppSmartDevicesEnvironment/gxmetadata/MyApp.android.json you got data but that just means that the virtual directory was successfully created. (which is good of course)
Then you need to check if the WCF module is installed correctly, in order to do that you could try to go to http://192.168.12.17/MyAppSmartDevicesEnvironment/MyAppOfflineDatabase.svc/rest or any other service in your KB. That goes straight to the service implementation. (you can check you web.config file in order to see the actual rewriting rules)
If that works it's certainly a URL Rewrite problem like Sandro and Guscarr suggested.
You can download and install the module from here: http://www.iis.net/downloads/microsoft/url-rewrite
Gcastano,
It seems that you're generating to .net, right?
If so, it could be some problem with iis rewrite module.
Anyway you might check gx software requirements...
It seems that REST services cannot be run on your IIS, as Sandro said, try installing URLRewrite.
Further info at http://wiki.genexus.com/commwiki/servlet/wiki?14575,Android%20-%20FAQ%20and%20Common%20Issues
I was unable to run typesafe activator in cloud9 :
The activator page loads OK but then I get the following error messages :
in the browser :
"Connection lost; you will need to reload the page or restart
Activator. It's also possible that Activator is open in another tab,
which causes this error."
in the cloud9 terminal :
"! #6j9pn9913 - Internal server error, for (GET)
[/home/stream?token=cba94...64394] -> play.api.Application$$anon$1:
Execution exception[[RuntimeException: Bad CSRF token for websocket]]"
Any help on how to solve this ?
Activator listens on 127.0.0.1 and is not even supposed to be listening on an external interface; it isn't completely clear to me why you can connect to it at all.
But however that connection works, it looks like the result is that the CSRF check fails. The CSRF check is checking that the query parameter there (?token=cba94...) matches a cookie that should have been set by the Activator page load. This demonstrates that the /home/stream request (to open the websocket) is coming from a page that has the cookie, i.e. from the same domain. Perhaps Activator doesn't know the domain you are loading the page from and therefore the cookie gets lost? Just a guess.
When the CSRF check fails that would then fail the websocket and cause the "Connection lost" error, though that error can also be caused by other things (such as proxies and antivirus software) that interfere with websockets.
You could possibly fix this, or take a step towards fixing this, by configuring the http.address system property to be picked up here: https://github.com/typesafehub/activator/blob/52012321b3a5a9f9dcf53582664e385d92763718/ui/app/activator/UIMain.scala#L130
You could also try setting application.defaultCookieDomain to the domain you are using (this is a Play config option and Activator's UI is a play app).
However:
you may well find other bugs in this scenario - it is not tested or supported
it is not at all secure unless you have some kind of authenticated proxy in front of it (there's no auth on the activator UI, and the UI has buttons to view and delete files, etc).
The activator shell command line is maybe a better option when you have your project build on a headless server, though I won't say running the UI is 100% impossible - you might be able to get it to work.