Depends on your setup. But first of all it is necessary to remember that Javascript is interpreted by the Browser, therefore the script needs to be accessible to everyone by the web.
If you define a site with the root in the folder /var/www/site1/html/
and tries to access a folder in /var/www/scripts
using ../../scripts
, this shouldn’t work. Remembering that the browser opens from the web, so it wouldn’t even be a valid URL because it would be below the domain root.
If you simply set your websites on /var/www
and access each one with the folder name in front of the domain, it would work.
I think the question you have to ask is whether it makes sense for it to be structured like this. Whether or not this folder below root will be part of the internal structure of your site if you use it like this.
Do sites 1, 2, 3 have any relationship with each other or do they only share these javascript libraries? And each has its own domain?
What new problems will this config cause? (if you are going to migrate for example, it will already be more complicated).
You could have a workbook with Javascript (where you modify them) and have an installation script (Bash or Makefile) that copies/replaces the files to the websites (all or only one of them) and then already arrow permissions/user.
In case I’d use something like make site1
or make all
to copy.
So it would still be the entire site contained inside your folder, but it would be easy to update. I think it would also be easier to test these libs before installing in production as well.
In fact the scripts only need to be visible on the web for your page to access. But using scripts from other domains is often blocked by browsers for security reasons.
Another option would be to release the use of symbolic links (symlinks) in apache or Nginx. By default this option is usually turned off for security reasons, as it is extremely easy to publish/access any server folder on the Web.
To avoid using symlinks, you can use hardlinks (nonsymbolic links), which basically duplicate the files, but keep the same inode on the disk. So the files will remain unique, but will have more than one reference in the disk tree. Very complex to maintain and usually not recommended unless you have a real reason for it.
The biggest problem is to maintain such a critical failure point for so many systems.
Any problems with this folder and all sites will suffer.
Working as an installable repository avoids all these problems and allows you to work more smoothly in a testing environment.
Tip: remove the tag
JavaScript
because your doubt has nothing to do with it.– Pagotti