Browsersync seems stuck loading the website when run in proxy mode. When using the same config but another website it does work, so it must be something in my local setup but I have been unable to figure out what.
I'm running it on Windows, proxying a ASP.NET 5 application which runs on localhost:5000. Directly navigating towards this location works fine. Trying to hook into the pipeline on ASP.NET's side signals the html is exported over the pipeline but the browser never receives a response and stays pending.
The logging output indicates no difference besides a different session and the obvious proxy url if I run it on another website, where also other sites on localhost seems to work (on IIS).
Configuration used (gulp):
gulp.task('browsersync', function () {
browserSync({
proxy: 'localhost:5000',
notify: true,
open: true,
logLevel: 'debug'
});
});
Related
We have an interesting challenge with our Nuxt3 based statically generated sites.
Essentially, we are a SaaS platform, and generate a website for each user, with the url pattern - xyz.example.com.
We have managed to make this work quite well. However, facing one challenge that we are unable to fix currently -- hmr has stopped working in our development stack.
Console is full of the following error:
web-socket.mjs?v=2e7270bf:56 WebSocket connection to 'ws://localhost:4000/ws' failed:
connect # web-socket.mjs?v=2e7270bf:56
web-socket.mjs?v=2e7270bf:5 [Content] WS Error: Event {isTrusted: true, type: 'error', target: WebSocket, currentTarget: WebSocket, eventPhase: 2, …}
warn # web-socket.mjs?v=2e7270bf:5
onError # web-socket.mjs?v=2e7270bf:30
error (async)
connect # web-socket.mjs?v=2e7270bf:59
setTimeout (async)
connect # web-socket.mjs?v=2e7270bf:44
onClose # web-socket.mjs?v=2e7270bf:38
web-socket.mjs?v=2e7270bf:4 [Content] WS reconnecting..
web-socket.mjs?v=2e7270bf:4 [Content] WS connect to ws://localhost:4000/ws
Any ideas on how to go about fixing this?
Currently -- to get nuxt to work in local dev stack, we have to add
xyz.example.com 127.0.0.1
in our /etc/hosts file. However, unable to figure out to get the WS connection failure errors to stop.
Any help would be much appreciated.
I'm building an Electron application (electron builder) and when deploying if I look at the dev tools it just says app:// at the top and also when sending any http(s) requests the origin is app://.
I have a feeling this has been a cause with some cookies not setting and CORS issues and I have been having.
In the createWindow function in background.js theirs a section that runs if in production with default as:
createProtocol('app')
win.loadURL('app://./index.html')
Setting that to my domain and building give just a blank window with the dev console saying chrome-error://chromewebdata
chrome-error when setting what I assumed to be the origin
Comparing this with Discord the top bar in dev tools says the discord website and also all requests have the origin of Discord.com
Discord dev tool header which makes me think this is app level rather than just http request level (axios/fetch)
Any ideas on how to change the origin
After doing some research into creating deep links, I've found that I basically needed my own protocol to do it (makes sense really).
So went to the documentation for Vue CLI Electron Builder and looked at the config section (https://nklayman.github.io/vue-cli-plugin-electron-builder/guide/configuration.html#changing-the-file-loading-protocol)
When electron:build is ran, it pulls in the options from vue.config.js. Adding in:
module.exports = {
pluginOptions: {
electronBuilder: {
customFileProtocol: 'myCustomProtocol://./'
}
}
}
And then also updating the win.loadURL('myCustomProtocol://./index.html') in background.js assigns the custom protocol to the app (all of this is in the documentation linked above)
Trying to build an Electron app using ember-electron and am trying to use emberfire to communicate with Firebase. Everything runs fine when running as a web app with ember s but when launching as an Electron app I get nothing but errors like this:
XMLHttpRequest cannot load https://www.googleapis.com/identitytoolkit/v3/relyingparty/signupNewUser?key=AIzaSyBYyuJ-1E3ufujlzdKhj8gE9I6QH8TreJE. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'serve://dist' is therefore not allowed access. The response had HTTP status code 404.
Is this a known problem or does anyone know a way around this? Unfortunately cannot simply add serve://dist to the list of authorized domains as Google doesn't consider it a valid domain name.
Update: I would still love to know if anyone has a possible workaround but I found a tool called Nativefier (https://github.com/jiahaog/nativefier) which works for my purposes. Since I am simultaneously developing a web app and a desktop app, once the web app is being hosted, can use nativefier to build the desktop app
I didn't try with electron, but played with node-webkit. Many problems related to origin can be solved by running local web-server: in main script run a web-server using express which serves your app. This is piece of code that I use to start local server:
let express = require('express');
let http = require('http');
let app = express();
app.use('/', express.static('dist'));
let server = http.createServer(app);
let port = 9000;
let maxPort = 50000;
server.on('error', function (e) {
if (port < maxPort) {
server.listen(++port);
} else {
alert('Your system has no free ports to start a web-server, which is needed for this app to work');
window.nw.Window.get().close();
}
});
server.on('listening', function () {
location = 'http://localhost:' + port + '/index.html';
});
server.listen(port);
I think that something similar should work for electron, too
I am trying to set up syslog so that we can have our app in different environments log to different files.
Everything works great for our development environment, but no logs are coming through for our staging environment.
Here is the snippet from our config file, 01-app.conf,
# staging
if ($programname == "api-staging") then {
action(type="omfile" file="/var/log/staging/api.log")
stop
}
# development
if ($programname == "api-development") then {
action(type="omfile" file="/var/log/development/api.log")
stop
}
user.* /var/log/other/user.log
stop
I have our config file start with 01 because the app logs go to multiple places if they respect the default config before our own.
Given that the development logs are getting routed correctly and that removing stop from the staging rule sends logs to /var/log/other/user.log, I am pretty confident there is not an issue with sending the logs to the box itself, but is somehow a problem with the routing.
An example log from /var/log/other/user.log that should be in /var/log/staging/api.log is this:
Sep 14 17:28:33 RD0003FF77E220 api-staging[58340]: "...", so I know that the programname I am looking for in the config is the correct name.
The syslog user did not have access to the staging directory so it could not write the logs there.
I am building an app in node.js and I’m using AWS EC2 to host it. However, my HTTP requests are not working.
My app is split into two repositories: app-ui and app-server. app-server contains all of my server side code/API’s. In app-ui, I am making simple POST requests such as:
$.ajax({
type: "POST",
url: "http://ec2-xx-xxx-xx/api/users",
success: function(data) {
console.log(data);
},
error: function(a) {
console.log(a);
}
});
However, I keep getting the net::ERR_CONNECTION_TIMED_OUT error.
Does anyone know what might be happening?
Add an inbound rule for the security group attached to your server for the specific port you're using.
I'm having the same issue this is because the amazon servers were down today, but take a look on your server to see if it is working in my case:
/etc/init.d/apache2 status
Response:
Active: active (running) since Wed 2017-03-01 02:21:53 UTC; 2h 3min ago
Docs: man:systemd-sysv-generator(8)
Apparently the S3 was one of the services down and also the routing system, if your server was located on AWS EST side you will find this issue, this affected several apps like HockeyApp and Trello
Take a look on the current status: status.aws.amazon.com
Of course assuming that you have the security groups, the elastic or static ip's set and configured and that you see this issue on all your site and not just on your API
I was struggling with the same situation. I managed it. Go to AWS -> login -> ec2 -> select the options in the left sidebar "security and groups". then select your default instance on the right side that is listed in the table then clicked the action button on the top of the table. that will show the inbound menu.
there you click the "add rule" button. there the type is "custom TCP" then you give port 8080 or whatever you prepare. then save it.
Now go ahead with postman it will work. enjoy your work. !!!!