Why is my meteor app getting these errors on firefox but not other browsers? - firefox

The web app that I am building in meteor works in chrome and I.E.(Other than a UI bug in I.E.) but it starts acting strange in Firefox. When I run it on my localhost and on the deployment to meteor.com, I don't get any errors in the console in the browsers' developer tools.
When I run it in Firefox, things start acting weird. On Mac OSX, if I run the app on my localhost and open it in FF it is just fine. However, when I open up the app that deployed to meteor.com via meteor deploy [my-app-url].com, I get the following errors but I can still use everything in my app:
Error 1:
mutating the [[Prototype]] of an object will cause your code to run very slowly;
instead create the object with the correct initial [[Prototype]] value using Object.create
Error 2:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource
at https://ddp--3071-[my-app-url].com/sockjs/info?cb=v9pygo9mzn.
(Reason: CORS request failed).
While right now I am not able to figure out what is causing the first error, I am mostly worried about the second error.
When I open up the app from it's deployment in FF on Windows 8, I get the first error once, and then I get the second error repeatedly and the app never loads(it just stays on my loading template from the iron router). My deployed app runs just fine on Chrome and I.E.
I don't send any kind of request to another server in my app, so I am not sure why I am getting a CORS request error. I have not set up SSL or began to make a certificate yet, so I am not sure if this could be causing this kind of error in FF as I got another exception on my login page in FF on my localhost saying that I shouldn't have password elements when I'm not using https.
Does anyone know what could be causing this?
Sorry that I provide any code, as I don't know what code I would post to solve this problem since I don't actually request anything from another server in code that I have written.
Thanks in advance for any responses!

If anyone is interested, it seems as if my combination of the aldeed:collectio2 package and one of my other packages was the cause of my problems. I removed this package and my issues went away.

Related

GoLang SPA returning 500 Internal Server Error on Refresh only

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?

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.

Unable to run typesafe activator ui in cloud9

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.

Janrain engage: token_url not called from Firefox

I have an application using Janrain Engage for login.
Everything works since few months, except on ONE machine from Firefox...
I have no clue for what reason, when I try to log-in from this machine (on my site or even on Janrain's admin site), I get the sign-in page, the I choose a provider, enter my information, validate and then, nothing happens !
Normal process trace is:
GET
https://XXXXXXX.rpxnow.com/signin/get_login_info?widget_type=auth&provider=google&time=1358864872301 [HTTP/1.1 200 OK 1144ms]
POST http://XXXXXXX.rpxnow.com/redirect?loc=yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy [HTTP/1.1 200 OK 2533ms]
POST https:// my_token_url_on_mydomain [HTTP/1.1 302 Found 3667ms]
On the faulty machine, I just have the first GET, and then nothing else...
The token_url callback is never called, so I even do not have any trace on my server.
The machine where the problem occurs is my personnal machine at home. Same login attemps works like a charm with Chrome or IE. I did'nt find any specific settings in my Firefox configuration.
I'm afraid some potential customers can get the same behaviour as me and go away... Is anyone experimenting similar problem ?
Froggy. You might have 3rd party cookies disabled in Firefox. That's the only thing I can think of that would cause that issue on a single browser. Go here for info on changing that setting: http://support.mozilla.org/en-US/kb/disable-third-party-cookies/

Debugging PHP code of a AJAX project using Eclipse PDT and Zend Debugger

I'm not sure if I'm right or not but it seems that Eclipse PDT + Zend Debugger have problems when it comes to debugging Ajax projects. I'm working on a project in which all of the requests are passed through a single PHP file (even resource requests like downloading images). And when I want to start a debug session in Eclipse after the first request returns successfully, second forth requests return the following error message:
A communication error occurred with the Zend Studio debugger due
to an unfinished debug session. Uncaught SyntaxError: Unexpected token
<
To reload the page click Refresh
It seems to me that since the first request is keeping the Zend Server busy, the second forth requests can not make a successful connection to it. It's in the case that I've configured the Eclipse so it won't stop at the first line of every page but still no luck.
Does this mean that in PHP + Ajax projects which requests are sent freely, it is impossible to debug? Has anyone tested this and/or the xdebug in a similar scenario?
Regards,
I just wanted to let my fellow developers to know that the same problem DOES NOT exist when I switched to xdebug.

Resources