Vue-cli: Incorrect configuration of 'base' in vue-cli-plugin-router

[soouup]

Version

3.4.0

Environment info

  System:
    OS: macOS 10.14.2
    CPU: (4) x64 Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz
  Binaries:
    Node: 10.3.0 - ~/.nvm/versions/node/v10.3.0/bin/node
    Yarn: 1.13.0 - /usr/local/bin/yarn
    npm: 6.1.0 - ~/.nvm/versions/node/v10.3.0/bin/npm
  Browsers:
    Chrome: 75.0.3770.100
    Firefox: 65.0
    Safari: 12.0.2
  npmPackages:
    @vue/babel-helper-vue-jsx-merge-props:  1.0.0
    @vue/babel-plugin-transform-vue-jsx:  1.0.0
    @vue/babel-preset-app:  3.9.2
    @vue/babel-preset-jsx:  1.0.0
    @vue/babel-sugar-functional-vue:  1.0.0
    @vue/babel-sugar-inject-h:  1.0.0
    @vue/babel-sugar-v-model:  1.0.0
    @vue/babel-sugar-v-on:  1.0.0
    @vue/cli-overlay:  3.9.0
    @vue/cli-plugin-babel: ^3.4.0 => 3.9.2
    @vue/cli-plugin-eslint: ^3.4.0 => 3.9.2
    @vue/cli-service: ^3.4.0 => 3.9.2
    @vue/cli-shared-utils:  3.9.0
    @vue/component-compiler-utils:  2.6.0
    @vue/eslint-config-standard: ^4.0.0 => 4.0.0
    @vue/preload-webpack-plugin:  1.1.0
    @vue/web-component-wrapper:  1.2.0
    eslint-plugin-vue: ^5.0.0 => 5.2.3
    vue: 2.5.2 => 2.5.2
    vue-eslint-parser:  5.0.0
    vue-hot-reload-api:  2.3.3
    vue-loader:  15.7.0
    vue-router: 3.0.1 => 3.0.1
    vue-style-loader:  4.1.2
    vue-template-compiler: 2.5.2 => 2.5.2
    vue-template-es2015-compiler:  1.9.1
  npmGlobalPackages:
    @vue/cli: 3.5.5

Steps to reproduce

1.Create a program with vue-cli3(includes router)
2.In vue.config.js: Set 'publicPath' with the domain which different from index.html(like: website on abc.com while publicPath on def.com)
3.Visit the website with invalid words(like '@'): abc.com?a=@

What is expected?

Just at abc.com?a=%40

What is actually happening?

Jump to abc.com/def.com?a=%40

---

we checked the vue-cli-plugin-router,found that in router config there is: 'base: process.env.BASE_URL',and in vue-cli-service the 'process.env.BASE_URL' was assign to the 'publicPath'. We remove 'base: process.env.BASE_URL',Then everything is ok.
So... Is 'base: process.env.BASE_URL' a right config?

[sodatea]

Next time please provide a reproduction.

---

I think we have made it clear in the documentation:
https://cli.vuejs.org/guide/mode-and-env.html#using-env-variables-in-client-side-code

BASE_URL - this corresponds to the publicPath option in vue.config.js and is the base path your app is deployed at.

So the problem is that we didn't take publicPath starting with a domain name into account and directly passed it to vue-router, while vue-router always prepends / to the base string.

I'm not sure whether we should strip the domain name in the CLI template or in router, though. /cc @posva

[posva]

if what the OP wants is to change the domain in the URL that is simply not feasible. Even if we support removing the domain from the base option (as we do when it comes from the base element), the page will stay at abc.com.

It would be a huge security problem if you could change the full URL while keeping the content 😅

[sodatea]

Oh got it.
So I think it makes more sense to do it on the CLI side - otherwise, it will be confusing to see the CDN domain in the base field.

[posva]

I think the base option makes more sense without the domain as it will be ignored anyway
But if the OP wants the URL to change from def.com?a=%40 to abc.com?a=%40, that's not possible

[soouup]

Need i provide a reproduction?
https://github.com/soouup/router-demo

[sodatea]

There are 3 places that referenced BASE_URL:

1. <link rel="icon" href="<%%= BASE_URL %%>favicon.ico"> in index.html. Here it means publicPath
2. ${process.env.BASE_URL}service-worker.js in PWA plugin. Here BASE_URL should be a relative path to the website root, we need to prompt a warning if it is not a directory path.
3. base: process.env.BASE_URL in router config. Here it means the website root (where the index.html resides).

If publicPath is a subdirectory path then all the use cases will be fine.
But in use cases where static assets are hosted on a CDN (thus publicPath becomes a full URL starting with a domain name), only the first use case makes sense.

[soouup]

There's another problem i could not understand.Why it cause this problem only when i use the char like '@',but use the char which no need to encode is ok

[zhj135]

@sodatea ,If I want to use CDN, can I just remove this line in router config?
base: process.env.BASE_URL

[sodatea]

@zhj135 yeah just remove this line for now.

[soouup]

@sodatea Can you help me to solve this puzzle 5 days ago😅?

[sodatea]

@soouup
https://github.com/vuejs/vue-router/blob/c3b0a335f7947584a7fc37ad0b87d55fe33dd039/src/history/html5.js#L63
This line, this.fullPath is an encoded path while getLocation uses decodeURI.

@posva Is is considered a bug?

[posva]

@sodatea I'm sorry, I really don't what we are talking about, if @soouup provides a boiled down repro explaining the problem they are facing with the @ character in the url, I can take a look. Going to ?a=%40 which is the right HTML spec compliant representation of ?a=@, yield the correct query object with {a: '@' } in IE, Chrome and Safari

[soouup]

@posva here:https://github.com/soouup/router-demo
if you use the query:'?a=@',it will cause this router redirection problem,but it will looks normal when you use the query:'?a=1'

[posva]

I don't see a redirection _problem_, so it must be something with your nginx config. To be clear, the correct query is ?a=%40, if the problem you are seeing is seeing that in the url instead of @. That's totally normal and cannot be changed

[sodatea]

@posva The initial problem is the misleading default base config in Vue CLI, which we now have a consensus that it should be resolved on the CLI side.

But during the investigation, we revealed a strange behavior in router that this redirection only happens when the url fragment contains a special character. After digging into the code of vue-router, I think it's because the ensureURL function mistakenly compared an encoded path with a decoded one, resulting in an extra pushState / replaceState call (see the link above). Normally this issue won't be noticed at all. But in this case user provides a wrong base url, so when vue-router reconstructs the url programmatically, it's quite noticeable.

[posva]

@sodatea Ah I see. As long as the problem does not appear when a correct base is provided, then it's okay