In my VueJS app I want to confirm a registration by traditional confirmation link.
This link looks like this
https://dev.xyz.com/auth/register-confirm?some=Data
Inside my register-confirm component I got the following method
beforeCreate () {
const query = this.$route.query // Is empty object on live page, works on localhost
this.confirm(query)
},
It is also very weird, that when I copy the original link to the browser and enter the site, it automatically cuts the query parameter, so the link looks like this
https://dev.xyz.com/auth/register-confirm
no matter what I type in as a query parameter.
Found the issue. We are hosting the site on AWS Amplify. It's caused by the rewrites / redirects.
GitHub Issue
Related
I just deployed my Vue app to my website using GitHub Pages.
The website is successfully hosted at https://astroorbis.com.
Here's the problem; When you click the "links" button at the top of the page, it successfully nagivates you to https://astroorbis.com/links, but when you try visiting the URL itself (typing in https://astroorbis.com/links) into your browser, it returns a 404.
There are other links that have the same error, such as /discord, /github, etc.
I tried the solution at Vue Router, GitHub Pages, and Custom Domain Not Working With Routed Links, but it failed as well.
What would be the solution for this?
As stated in this section of the HTML5 mode
Here comes a problem, though: Since our app is a single page client side app, without a proper server configuration, the users will get a 404 error if they access https://example.com/user/id directly in their browser. Now that's ugly.
Not to worry: To fix the issue, all you need to do is add a simple catch-all fallback route to your server. If the URL doesn't match any static assets, it should serve the same index.html page that your app lives in. Beautiful, again!
So, the solution would be to use something like that
const routes = [
// will match everything and put it under `$route.params.pathMatch`
{ path: '/:pathMatch(.*)*', name: 'NotFound', component: NotFound },
]
On Netlify, you also need to add the following for it to work
/public/_redirects
/* /index.html 200
So I'm not sure about Github Pages but you should have something similar there, some way of catching all routes and sending them to the index.html of your initial SPA page load.
Otherwise maybe just give a try to Netlify with the _redirects configuration.
Maybe this article could help regarding Github pages.
The hack in your given link seems to be the only viable solution but it's still bad for SEO so yeah, depends if you want any (I guess so).
In that case, you could try Nuxt.js, Gridsome or Vitesse if you want to have some statically generated pages (best approach regarding SEO).
I created a website with several pages on Vue.js.
Everything is working fine locally, but when I deploy to Heroku, all pages are only working when I click on an internal link in my menu that redirects to the corresponding page (using router push).
When I try to access directly /any-page from the browser I get a 404 with a message saying "Cannot GET /any-page" whereas the same page is displayed correctly via a click on a link.
As I mentioned when I locally serve my app I don't have this problem.
I really can't see where this can come from, thanks in advance for your help.
There's a deployment guide specifically for Heroku in the official Vue CLI documentation.
You'll quickly notice the relevant information:
static.json
{
"root": "dist",
"clean_urls": true,
"routes": {
"/**": "index.html"
}
}
For SPA's (Single Page Applications), you'll want to point every route to the index. Vue router will take care of navigating to the proper page.
Heroku is serving the contents of your Vue build folder. Since Vue builds the app as a single index.html file, only the main route works.
Vue doesn't actually navigate to the route, it rather rewrites the the browser url using the history API and handles the loading of the new route.
You could use one of these options:
OPTION 1
You could use mode: "hash" to fix routes when reloading the page. However this will add a # before every route.
const router = new VueRouter({
mode: "hash",
routes: [...]
})
OPTION 2
Write an Node.JS (eg Express) app that routes every request to your index.html file. This is called a middleware
Reference: https://router.vuejs.org/guide/essentials/history-mode.html#example-server-configurations
I currently develop an SPA web application using nuxt 2.7.1 as part of my bachelor's thesis.
On some of my pages I have set up beforeRouteEnter navigation guards to check whether a user may access the page. If not, I want to redirect the user to a dynamic route (namely /info/1).
When accessing the page protected by the navigation guard, Nuxt displays an error page stating This page could not be found, although the URL is correct and a simple reload at the error page correctly leads me to the dynamic route.
I am currently using the navigation guard in the following way:
beforeRouteEnter(to, from, next) {
if (!isValidAccess()) {
console.warn("illegal access");
next(`/info/1`);
} else next();
}
For clarification, my directory structure looks as follows:
pages
|__ info
| |__ _index.vue (redirect target)
|__ shop
|__ _index.vue (with navigation guard)
I have tried experimenting with the argument passed to next() but so far without success. When implementing another beforeRouteEnter in the target route and logging the to parameter, everything seems normal.
I hope you guys can help me. I already spent too much time on this issue.
Best regards
EDIT:
I have created a minimal example, where the routing to a dynamic route works without problems... https://codesandbox.io/embed/codesandboxnuxt-t1d0e
I will update the question when I find the solution to my problem.
This works for me - on landing page (index) you get redirected to your /info/1 dynamic route. Is this what you want?
https://codesandbox.io/embed/codesandboxnuxt-vvbrt
The only thing I've done was wrapping your dynamic route in <no-ssr> tag to get rid of an error. Your component is not compatible with SSR.
attempting to deploy a vuejs, express app to heroku. The app displays, but cannot access the api, because heroku seems to add 'undefined' in the middle of the base_url. Everything works locally as expected.
Here is my heroku config var:
BASE_URL: https://goore-todos.herokuapp.com/
Here is the Vuejs component api request:
fetchTodo () {
let uri = process.env.BASE_URL + '/api/all';
axios.get(uri).then((response) => {
this.todos = response.data;
});
},
As mentioned, this works locally.
the console shows the following error:
VM71:1 GET https://goore-todos.herokuapp.com/undefined/api/all 404 (Not Found)
and the view is empty.
requests to https://goore-todos.herokuapp.com/api/ via Postman work as expected.
In this case it looks like process.env.BASE_URL is undefined. As it is undefined, the url you're trying to access is considered to be relative. That means it uses your current domain and appends the path to it.
If your frontend and backend are running on the same domain there is no reason to try to pass the API url as a variable as you can just use relative URLs.
If you want to access the URL via an environment variable it is a bit trickier with a frontend app. The Vue app is running on the user's browser, not on your server so you can't directly access it.
I had this problem and had to go through and hard code all of my URLs with the heroku URL. I tried resetting the config variables in Heroku which had an extra slash at the end, but in the end hard-coding each API call was the only thing that fixed it.
My new Ember-CLI app uses a user portal slug in the URL to display proper information to the user. For example (fake URL): http://my.server.portals.com/robertplant
I'm using a combination of router and adapter logic to get the user portal name form the url slug, and then display the data related to it. It probably needs some more work, but here's what I have so far:
Router code extract:
Router.map(function () {
this.route('portal', {path: '/:portal_slug'}, function () {
this.resource('account', {path: '/'});
});
});
Adapter code extract (for hitting the right API end point based on portal):
namespace: function () {
var portal = window.location.pathname.match(/^\/([^\/]*).*$/)[0];
return 'abc' + portal + '/api/v1';
}.property().volatile(),
I can hit the app locally (e.g.: http://localhost:4200/robertplant/) with no issues. It runs using Ember-CLI’s built in web server.
However, when I move the app to the server, which runs Apache, and try to hit it (e.g.: http://my.server.portals.com/robertplant), I get:
Not Found
The requested URL /robertplant was not found on this server.
Which makes sense I suppose, since there isn’t really a directory named the same as the slug. However, there has to be a way, I would think, to tell Apache to ignore the problem it thinks it is having, and allow the app router to handle it. The local web server is doing it somehow.
Ideally, the solution would leave the URL displayed the same. Also, re-writing the request to point to something like http://my.server.portals.com?slug=robertplant causes Ember-CLI assets to be looked for at the wrong path (can't set baseUrl dynamically).
I'd appreciate any feedback on how to set up the app in Apache to allow for this to happen.
Solution:
Say the current subdomain is my.portal.com. Create another subdomain that points to the same directory on the server. Name it my2.portal.com
For the first subdomain, add a mod rewrite rule which rewrites something like
http://my.portal.com/joe_blow
as
http://my.portal.com?portal_slug=joe_blow
This allows you to hit the url without a 404.
Set the asset paths (in the generated index.html) to point to the second subdomain. E.g.:
http://my2.portal.com/assets/app_name.js
This allows the app to find the assets without the issues associated with the rewrite or the slug in the url.
Of course, you can also place the assets anywhere else, including an S3 bucket. But in my case, I have a constraint of having to store them on the same server/network for security reasons. And my way you can deploy all the files to the same location.
That's it! Works like a charm.
The only thing I'm not fond of, is having to edit the index file after it's generated. I will try to automate it at some point.