[Enhancement]: Add subfolder URL path instead of using a subdomain

[maartenbrakkee]

Describe the feature/enhancement

For reverse proxy usage with a subfolder instead of a subdomain. E.g., /audiobookshelf/ instead of /.

[unclebacon-live]

I second this.

[whiskywaffel]

Would be a nice. Is there any chance this gets implemented?

[sandreas]

+1
I would suggest to use process.env.serverUrl wherever possible...

Maybe it helps collecting code permalinks, that maybe need to be adjusted?

Probably (server and client-config):

• audiobookshelf/server/Server.js

  Line 185 in f34ebdc

  app.use(express.static(Path.join(global.appRoot, 'static')))

• audiobookshelf/client/nuxt.config.js

  Line 31 in f34ebdc

  src: '/libs/sortable.js'

Maybe (client):

• audiobookshelf/client/pages/index.vue

  Line 8 in f34ebdc

  redirect(`/library/${store.state.libraries.currentLibraryId}`)

• audiobookshelf/client/pages/login.vue

  Line 40 in f34ebdc

  this.$router.replace(`/library/${this.$store.state.libraries.currentLibraryId}`)

What about the app?

[sandreas]

@advplyr

How is the state of this issue? You said in #570:

we need to add a base url from env variables for the client side to work. Then there is the server and mobile apps. I've attempted to add this once before and it was more complicated then it seems.

So there is work to do in:

• Client
• Server
• Mobile Apps

I did not find a branch with your failed attempt, but I would really like to help you with this issue and submit a PR, if you don't have the time. I would just need your help to point me into the right direction... the collected parts of code above might be a first step, but I do not know, what code parts may be also critical / necessary...

Should I fork and create a branch / PR for discussion? Or would you just list the things you tried out and failed with?

Thank you.

[advplyr]

Thanks, I could use some help.
The first step is the base url will need to be passed in as an environment variable for docker or specified in the config file for debian.

The part where I got hung up was passing that environment variable to the Nuxt.js app so that we can set the base url in the nuxt.config.js file. I'm not sure the best way to handle that. I think setting that would handle the web app client portion of this.

I'm not sure exactly what would be needed on the server yet.
The mobile apps would need to store the base url separately. I haven't gotten too deep into this since I got hung up on the web app client.

We can chat about this in discord also if that is easier or start a discussion in GH whichever you prefer.

[sandreas]

Progress update:

• First steps to integrate BASE_URL into the /server component: master...sandreas:master
• Got the client working - some issues with logos and audio files, but I got a user interface for the client, client changes will follow and are currently NOT part of the fork

[advplyr]

Oh great, how are you passing the env variable to the nuxt app?

[sandreas]

Oh great, how are you passing the env variable to the nuxt app?

That is something I am working at. I tried some static options first and it worked partially with the options router and baseUrl:

  router: {
    base: '/audiobooks'
  },
  axios: {
    // baseURL: process.env.serverUrl || ''
    baseURL: "/audiobooks/"
  },

The nuxt-config is very fiddly here. A missing / or one too much at the wrong place and it does not work at all. Seems that this is influenced by the server config in dev.js / index.js. I'm not even sure, wether that default value for BASE_URL should be `` (empty string) or / (slash).

I'm currently trying to figure out a reliable way to make this work and if I have this, I'll try the dynamic configuration. There is also this ticket: nuxt/nuxt#7312 which might help to configure it runtime, so that one does not need to retranspile the whole client for changing the baseUrl.

Maybe BASE_URL should also be renamed to PREFIX (like here), since we only wanna change the last part of the url... we'll see, I'm pretty busy atm, maybe this takes some time to figure out.

[advplyr]

Prefix is better since that is all we want passed into the env variable.

I was having the same issue you are working on. We can use the runtime config but the problem I had was actually accessing that env from the client. The env's available on the server aren't available in the nuxt app.

[sandreas]

Prefix is better since that is all we want passed into the env variable.

Ok, I'll regard that. Currently it is an experiment - not a working thing. Maybe I have to rethink everthing.

I was having the same issue you are working on. We can use the runtime config but the problem I had was actually accessing that env from the client. The env's available on the server aren't available in the nuxt app.

I'm aware of this. I would prefer this

router: {
  base: ""
},
axios: {
  baseURL: ""
},

because without a leading slash using relative references it would work everywhere without any runtime changes or variables. It seems that nuxt does not allow `` (empty string) and replaces it with /. I would see that as a `nuxt` bug, because it makes a very important feature unusable - REAL relative paths.

Instead of using /_nuxt/0sdrcie.js it would use _nuxt/0sdrcie.js, result:

• http://mydomain.com/audiobooks/index.html + /_nuxt/0sdrcie.js => http://mydomain.com/_nuxt/0sdrcie.js
• http://mydomain.com/audiobooks/index.html + _nuxt/0sdrcie.js => http://mydomain.com/audiobooks/_nuxt/0sdrcie.js

That is what I am investigating.

Here are some links:

• Option for relative paths nuxt/nuxt#2892
• Add publicPath type of option to generate nuxt/nuxt#1052
• https://stackoverflow.com/questions/53851269/nuxt-axios-dynamic-url

[advplyr]

@sandreas I missed your last comment here. Are you still working on this? I can look into this today

[sandreas]

@advplyr Not really, my son was born 6 days ago, now I don't have the time. Would love to see you look into this, otherwise this will take a lot of time, the next 3 weeks no development ;)

[advplyr]

@sandreas Congrats! Thanks for the update

[RichardMawdsley]

Hope your new son is doing well @sandreas! - He's what, 4/5 weeks old now? - He must be sleeping through the night and barely disturbing you, right?.. right!? :D

I have no way of helping with the development other then offering to be a guinea pig beta tester when it gets there!

Fingers crossed for this in the near future.

[sandreas]

@RichardMawdsley

Hope your new son is doing well @sandreas!

Yeah he is alright thank you.

He must be sleeping through the night and barely disturbing you, right?.. right!? :D

Unfortunately this is not the way it goes ;-) However, its surprising how insomnia gets you back to development. But @advplyr was very right: nuxt is really nasty here. I tried many things to get this working reliably but atm I'm out of ideas... My branch contains a PARTIAL solution for ONE problem and combines multiple points of failure to one. But since I'm not a nuxt expert and it was really frustrating to debug this, I'm not going to invest time here in the next weeks.

I have a lot of projects going on and since this problem would be "nice to have" and is not mandatory for my system to work, I deferred my efforts to get this working.

[1nVitr0]

Am I correct in the assumption, that this is already implemented using ROUTER_BASE_PATH, but doesn't get picked up by nuxtjs? (Whis is because nuxt has been compiled to static files)

I am happy to help here in any way possible. Just checking the desired behavior here: Do you intend to solve this inside the server code, or do you want to change the nuxt target type?

[advplyr]

Am I correct in the assumption, that this is already implemented using ROUTER_BASE_PATH, but doesn't get picked up by nuxtjs? (Whis is because nuxt has been compiled to static files)

Correct. The server side part should be good to go although I haven't tested that env variable in a while.

I am happy to help here in any way possible. Just checking the desired behavior here: Do you intend to solve this inside the server code, or do you want to change the nuxt target type?

I'm not sure what the best way to solve it is. My initial thought is that we have the server build Nuxt programmatically. I haven't spent a lot of time looking at the internals of Nuxt but there is some info about this approach https://nuxtjs.org/docs/internals-glossary/nuxt/.

I would really appreciate your help or feedback if you want to dig into any of this. I'm also active on the Discord/Matrix servers if you want to chat about it.

[advplyr]

I took a non-traditional approach when first setting this up because I tend to learn as I build, so I just didn't know at the time.

[1nVitr0]

Thats the best way to learn things, at least for me. Give me a few days to fiddle aroundwith it, haven't used nuxt in a while. Given the amount of free time currently, it will probably be a bit hacky, bu I'll make sure it's robust (That is if I manage to find one).

This is an amazing project, I spend 2+ hours a day listening to audibooks. So I will definitely invest more time into this in the future.

[1nVitr0]

Right. After a little fiddling and digging through nuxtjs changelogs, I have come to the following conclusion:

• NuxtJS does NOT natively support a dynamic base path when using a static build target
• Options to get around this I came up with:
  1. Recompiling the target when the base path changes
  2. Running nuxt using node directly and proxying express requests to it (alternatively using nginx or similar around it)
  3. Running Nuxt programatically (as @advplyr suggested)
  4. Manually updating the build files when the base path changes

I think they all have their pros and cons

• i. is robust and includes minimal code changes, but bloats the docker image with nuxt dependencies and drastically slows down startup. Also depending on the nuxt dependencies, it might struggle with cross-platform
• ii. is robust, efficient and doesn't bloat the docker image very much, as nuxtjs can compile it's dependencies into the build. But it requires some drastic code changes, as we can no longer rely on the static serving of files to detect the request's targets
• iii is robust, efficient and doesn't bloat the docker image very much, as nuxtjs can compile it's dependencies into the build. But it requires some code changes, as nuxt is used as a middleware, this might also need some work when running the client independently
• iv. requires minimal code changes, is very efficient and minimally impacts startup performance. But it relies on nuxt compiling into a known structure and may break when updating to a new version

I am currently dabbling with iv. as a temporary solution. That does seem to work until the login screen, after which my version currently crashes. (It does not connect to the websocket, so that may be the issue). For a permanent solution, I think either i. ii or iii. are fine, although I personally lean towards iii. / ii as node is used for the rest of the application anyways. ii. would give somewhat more freedom when running client and server independently, iii might be easier to integrate into express and only runs as a single instance.

---

Update

I have gotten around the issues with crashing my client when manually updating paths. I am currently working on running and accessing the socket under the given base path.

[Danathar]

I'd like to present an additional use case, which is how I use it although it seems that everyone already supports the idea. I currently use Nginx's reverse proxy with different subfolder paths to distinguish between Apache Guacamole (a remote desktop app over the web that also utilizes websockets) and Wetty (a web-based terminal). I would prefer to use a subfolder URL for Audiobookshelf, as it would eliminate the need to obtain another certificate for an additional subdomain. I use Let's Encrypt for my certificates which makes the process of obtaining and managing certificates relatively simple and automated. However, having fewer certificates to manage would still simplify the process.

[sandreas]

I use Let's Encrypt for my certificates which makes the process of obtaining and managing certificates relatively simple and automated. However, having fewer certificates to manage would still simplify the process.

A little off-topic: You could use letsencrypt wildcard certificates (*.domain.com), which work perfectly fine on my system.

[Danathar]

I use Let's Encrypt for my certificates which makes the process of obtaining and managing certificates relatively simple and automated. However, having fewer certificates to manage would still simplify the process.

A little off-topic: You could use letsencrypt wildcard certificates (*.domain.com), which work perfectly fine on my system.

Yea I guess it’s slightly off topic. I forgot to use wildcard certs when I first setup my system. I don’t think it’s trivial to convert once you have gone down the road of individual certs. I think I would need to revoke all my certs and start over.

[MagiX13]

I could be entirely wrong here as I never worked with anything from the underlying stack, but isn't this supported in nuxt using the runtime config, as described with basically the exact example here

publicRuntimeConfig: {
    axios: {
      browserBaseURL: process.env.BROWSER_BASE_URL
    }
  },
privateRuntimeConfig: {
    axios: {
      baseURL: process.env.BASE_URL
    }
  }

Giving a bit more context on the runtime config from here

The runtime config has built-in dotenv support for better security and faster development. The runtime config is added to the Nuxt payload so there is no need to rebuild in order to update the runtime configuration...

[advplyr]

@MagiX13 That is for axios and not for nuxt which is generating all the paths during build. There is a detailed discussion in #1746

[gardiol]

Is there any news on this? I would also like this feature if not yet implemented.

[gaarysn]

Hi. What shoud I do if my server already have subdomain (like srv.server.com). How to configure nginx and ssl to audiobookshelf.srv.server.com? Will audiobookshelf work like this?

[Danathar]

Hi. What shoud I do if my server already have subdomain (like srv.server.com). How to configure nginx and ssl to audiobookshelf.srv.server.com? Will audiobookshelf work like this?

Create a server block in nginx like:

server {
    listen 80;
    server_name audiobookshelf.srv.server.com;

    location / {
        proxy_pass http://localhost:13378; # Replace with the port Audiobookshelf is running on
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

You could set that listen to whatever you like, but if you use 443 you'll need to set up certs. I set mine up with letsenrypt. The block above was spit out by AI, but it's similar to mine except I've added encryption.

[farfalleflickan]

@1nVitr0 I do not mean to nag, but would it be possible to know the progress status on this?