`set-cookie` doesn't work in dist generate by `npm run build` - vue.js

I have a vue frontend server and we use cookie to control login state with a simple backend server.
The problem is, set-cookie works fine in production model by running npm run serve.
But after I pack it into a dist folder and serve it by serve -s dist, set-cookie from backend response doesn't work, and there is no warning or hint in the browser.
I not familiar with the frontend, so feel free if you have any thought. Any information may help me a lot, thanks!

I fixed it finally. Thank to #Luke again!
The biggest mistake I made is I didn't check whether cookie had been set.
I don't think this will completely solve your problem but it may help a bit: To see whether your cookies are being set in Chrome do the following: 1) Click F12 (this opens the developer tools.) 2) Click on the Application tab. 3) Click on the Cookies option on the left. 4) Keep an eye on what cookies are being set as you interact with your different server environments. – Luke
Vue proxy will keep you away from cookie problems while you are developing with npm run serve, but it won't give any help if you pack it by npm run build.
So you need to remember to set withCredentials = true, in your project. I use axios for example, so the good way should be setting axios.defaults.withCredentials = true; in main.js.

Related

Problem when publishing Nuxt.js app on shared hosting

Okay, I'm trying to publish my Nuxt.js app on my web host but I've run into some issues. I do not want a static site.
After running "npm run build" locally, I transferred the files to my web host with FileZilla. Then I'm supposed to fill in the statements shown in the picture below.
And this is where my problems begin. The app does not want to start at all, and i am nor sure what to put as "Application startup file". And according to my web host, the overall problem is that there is no startup file for Nuxt applications. I am completely new to Nuxt and do not have that knowledge and therefore I now turn to you, is it the case that there is no starup file for Nuxt?
The web host also mentioned that it is more difficult to get a Nuxt application upp and running on shared hosting, is that correct? Will I not be able to get my app up and running in this place?
My web host had received this error message when they tried to start my app. Maybe there are some clues in there to find.
ERROR Request failed with status code 404 15:58:38
at createError ({{my-adress}}/14/lib/node_modules/axios/lib/core/createError.js:16:15)
at settle ({{my-adress}}/14/lib/node_modules/axios/lib/core/settle.js:17:12)
at Unzip.handleStreamEnd ({{my-adress}}/14/lib/node_modules/axios/lib/adapters/http.js:260:11)
at Unzip.emit (events.js:315:20)
at endReadableNT (internal/streams/readable.js:1327:12)
at processTicksAndRejections (internal/process/task_queues.js:80:21)
Hope someone can help!
Without some more context, I can't tell you exactly what your issue is but I suspect it is to do with how the web server on your shared hosting is configured to serve files. When you visit a route, it's not correctly finding that index.html page.
A Nuxt static application deploys with a structure where each page route has its own rendered index.html page inside a folder - if I'm not mistaken.
Your web path may look like example.com/hello but in reality it resolves as example.com/hello/index.html. Some web servers will struggle by default with this structure if not setup correctly.
Honestly, if I were you I'd deploy the project to either Vercel or Netlify.
Both have incredibly generous free tiers that will let you host your application for (if it's not making any money) for a very long time at a good scale.
They both run on automatically scaling infrastructure so you don't need to worry how much resources your site is consuming or how many users you get. It will maintain responsive and reliable without any detriment to load speed.
They'll also automatically handle building and deploying the application on your behalf. All you need to do is connect the service to a Github repository.
They also provide CDN's and other optimisations such as compression for you as well to make your site much faster.
Nuxt has a dedicated page on Netlify deployment. I recommend you give it a read:
https://nuxtjs.org/docs/2.x/deployment/netlify-deployment/
When you do npm run build (or npm run generate), your final content will be available in the /dist directory (the console should tell it to you at the end). It contains an index.html file, this is the one that serves as entry point.
Btw, before going any further double check that this is working locally:
npm run build
npm run start (URL and port will be given to you)
If it works locally, you can proceed.
.nuxt is essentially used for development purposes, caching and so on. And should not be tracked by Git, nor deployed.
I'd like to advice against using FTP for deploys (especially if not secured). Prefer a more modern way, like pushing your latest git commit and let the platform handle the hook or fetching your new code and bundling your app for you.
As recommended above, Netlify is one of the best place to easily host your Nuxt app: simple, fast and headache-free. Also, check #jordan's link about the various platform deployments, you may find yours (if it's good/well known).
I may come here a little late, but this is the way I configure the "Application startup file" when deploying a Nuxt app in shared hosting using the NodeJS Selector app (that commonly you find in CPanel)
Since basically the startup file in NodeSelector is executed as if you would run node startup_file.js, you can create an app.js at the root of the project, and add the following code:
require('#nuxt/cli').run(['start']);
This is basically the same as nuxt start, which is basically the start script in your package.json
Hope this can help others having the same issue. I leave here the same issue posted in git:
https://github.com/nuxt/nuxt.js/issues/7192

VueJS Application Caching Issue - IIS 10

I have a VueJS application that is deployed to a local IIS 10 server for intranet use.
Trouble is, the index.html file is getting cached and a forced, manual clearing of the browser is needed to see updates. I understand there are ways on the server side to prevent this, but I'm unclear based on what I've read so far as to what the proper way of making sure the html file isn't cached is (js, css and the like are, of course, not cached since they have the additional value appended to the file name during build.)
I'm very much a novice when it comes to the server side of things, so any insight would be greatly appreciated. Thanks!
Which packaging tool do you use in your project? Generally speaking, Webpack/Vue-CLI has settings for prevent the file from caching in the browser on the client-side. In other words, it adds hash value to output files which could flag the version we build recently, this will result in the client browser to forcibly request the new version file.
In the Webpack.config.js
output: {
filename: '[name].[contenthash].bundle.js'
}
https://webpack.js.org/guides/caching/
See these links for more details.
Browser cache problems with webpack chunks and vue.js components
how to force clearing cache in chrome when release new Vue app version
VueJS/browser caching production builds

Ngrok and npm explaination Wix API AuthO

Am working on a API with Wix, and ive been able to get everything working, But there is one eliment i cannot automate or account for because i have no idea how its working or understand it properly.
I have been following: https://dev.wix.com/api/rest/tutorials/create-your-wix-app
It advises me to use Ngrok and also Npm after downloading some sample skd.
WHen setting up the App, it asks for a Redirect URL (When users authorize your app, we’ll redirect them to this URL with a temporary authorization code.)
It also asks for: App URL (When users start to add your app from the Wix App Market, we’ll redirect them to this URL.)
What i cannot understand is how Ngrok allows and uses the urls in the tutorial
As there is no physical files for these calls?
https://<NGROK_STRING>.ngrok.io/login and https://<NGROK_STRING>.ngrok.io/signup
I peronsally thought it was just a URL it called and passed back the Auth code, So i created a PHP page that fetched the string behind code: in the url so it can email me or save to file,
But this just does not work.
(I have it working in ngrok and npm, but i cannot have these running every time a user wants to download the app and link into our system)
I cannot understand the use of npm and ngrok, am presuming there is some sort of handshake somewhere.
Is this the correct way, do i have to install these programs on the a dedicated server and have them running at all time incase someone installs the app?
Is it not possible to just have the AUth code sent to me so i can finish the setup, generate a refresh token and be done with all the ngrok and npm
I'm not sure if I understand you correctly. So I'm gonna explain NPM and NGROK quickly.
NPM = node package manager -
npm is simply a package manager, so you can use it if you like to. Especially with node.js you are most likely gonna be using it. But with PHP npm might be used in your development enviroment so for example PHPStorm to get the packages you need. So no direct connection to WIX.
NGROK -
Is used to redirect traffic from a semi-permanent ngrok URL to a likely dynamic IP like from your Computer. In my case I work on localhost, and NGROK just relays the calls from wix to my localhost where the application is running. This is needed, since stuff from the internet can not simply access a computer. That's what NGROK is for.
If you have a ready application, you should not need ngrok, aslong as you have it running on a server somewhere. "Just" replace your NGROK urls with the actual URLs of your server.
I hope this helped =)

Angular Server Side Rendering ; How to keep it running forever?

I am trying to host an angular server side rendering app. Whenever I try this command npm run serve:ssr it runs fine and after a while it stops automatically. I just have 2 questions.
How do i keep it running forever ?
Is that the right way to do for a production ready app?
Please suggest.
I would follow angular's advice and discourage node and express as servers. But sometimes you have to do it. If you do care about security ( a lot ) I would crawl the entire site and drop the results in a static NGINX server.
In either case you should use angular universal with a grain of salt.
And to keep things runing forever you can turn the npm serve:ssr into a deamon (unix) so that the system keeps it on. Or simple change it to : while true; do npm serve:ssr; done

how to test open graph on localhost

I've done a lot of research and haven't found a definitive answer to this. Is there anyway to test the open graph on localhost? I don't haven any issues using the graph api on locahost.
I've changed my website url in the app settings and have even tried setting up a domain in my hosts file but the debugger linter for open graph tries to use the actual domain instead of my localhost and when using locahost directly the linter completely fails connecting.
Does anybody have any workarounds for this?
Using a local proxy is the right solution. ngrok didn't work for me neither.
A similar tool that did work with facebook debugger is localtunnel ✅
npm install -g localtunnel
lt --port 8000
# or using npx without installing localtunnel
npx lt --port 8000
Generates a url that looks something like https://<random_hash>.localtunnel.me/. Using this url in facebook open graph debugger worked for me as of October 18th 2017. I only had to hit Fetch new scrape information button. 🍻
Cool thing about localtunnel is that you can easily host your own localtunnel server with github.com/localtunnel/server so if it ever stops working with localtunnel.me, you can run your own somewhere in the cloud ⛅
You can use ngrok to create a random public subdomain that routes to your local webserver very easily, even through NAT or firewalls.
Just download ngrok and run ./ngrok http 8080 (assuming 8080 is your local webserver http port).
This will create a random subdomain like http://38a84a97.ngrok.io/ that routes to your local webserver and that you can use with Facebook to test your open graph tags.
Its very simple to test Open Graph in any local environment using Chrome or Firefox using plugins. I have used one to quickly show in chrome how the Open Graph looks to the viewer to test results. Here is a quote of what it does.
This extension shows how people will see your site in the most popular
social networks This extension is for professionals who creates a
media content.
To check meta-information of your site or article just open it in a
Chrome and click extension's icon. Also you could add an URL manually.
Here is a direct link to the plugin (Chrome)
Firefox add-on
As a bit simpler approach you can use a browser extension like https://socialsharepreview.com/browser-extensions - which will show your Social Cards directly in the Browser (which of course might fail, if you wrongly didn't set them serverside :))
To test open graph (and Twitter cards) I also had to expose localhost (Docker) to Facebook and Twitter. I used Serveo
It works very well for this, no need to install anything as it works with ssh port forwarding.
$ ssh -R 80:localhost:3000 serveo.net
Then navigate to the url given, and there you go.
You have to setup a public domain which points to your public ip address.
Use dynes.org or a similar service and setup your router to forward your port 80.
There are several tools you can use for serving something up over your localhost, each with varying degrees of functionality.
I prefer (obviously) http://forwardhq.com
Other great options here: http://devblog.avdi.org/2012/04/27/http-forwarding-services-for-local-facebook-development/
If anyone is looking to preview the :og tags on while developing on subdomains (using lvh.me) in localhost. You can use https://serveo.net.
Simply use following command to forward your local server requests. No installation required.
ssh -R yoursubdomain.serveo.net:80:yoursubdomain.lvh.me:3000 serveo.net
you can put your desired port in place of 3000.
Reference: https://blog.aarvy.me/2019/09/20/expose-local-apps-having-subdomains-to-web/