Best way to have two output (nested) folders
-
Hello everybody,
The biggest part of my application is private behind a login. So, I should compile my application in a root folder where the public files are going to be (vendor.js, main.css, login.js, index.html, login images…). Then inside this folder there should be another one (for example ./App/…) that is going to be protected by apache in production, with all the app code, images, documents…
What’s the best way to achieve something like this?
Thanks for your time,
H25E
-
What do you mean protected by Apache?
Scott
-
An URL rewritting map script. If client tryes to fetch a file inside the ./App/ directory, the script will check credentials and return to login/error if needed.
-
I’m not an Apache expert, but it seems like you are attempting something out of the ordinary. I don’t believe locking down directories to protect assets via Apache htaccess is a workable solution. I’d make my API serve the files and have the auth logic in my API control access. The files for your app in general should be made public, even if most of your app isn’t public. You should control what the users can access via the router in the app.
Or, I’m just not in the know of what you want to do, and if true, I apologize for wasting your time.
Scott
-
No please, no need to apologize.
The control of what is accesible or not is done in the server, with php (plain, no framework in the backend) sessions and apache mod rewrite (for this private directory). There is confidential information shown in the app (images, documents, data returned by php scripts) that hasn’t to be accessible for unauthenticated users. If I control this only in the router the confidential files/data would be accesible from outside with web scrapping/robot.
I don’t know what do you mean with API in your answer.
EDIT: I’m doing something wrong? Should I do it different? I’m far to be an expert in web development, so any help is welcome.
-
Well, is your PHP delivering html? If yes, you are doing something not really ideal with Quasar. Quasar is meant to be an application frontend framework, i.e. for SPAs, PWAs, Mobile apps, Electron apps, etc. You’d connect it with your backend via an API (which PHP can also do). I hope that makes sense.
Scott
-
No.
Apache directly serves the files that the quasar CLI outputs in the dist folder. No PHP here.
PHP only checks if the user has a valid session. If not, rewrites the requested URL to a safe one (for example ./private/confidential.pdf || ./private/embarassing.jpeg || ./private/non-pulic-bundle.js || … to for example: ./index.html/#/login). Or return an empty response with an error status code, and web app will redirect conviniently. The point is to not serve protected files to unauthorized clients.
There are also private php scripts that returns confidential JSON data that gets fetched with ajax request to populate certain contents. But PHP isn’t directly delivering html.
So that’s why I want to have all the protected files in (ideally) one subfolder inside the dist folder when building.
Does that make sense?
-
Yes. That makes sense. My past experience with PHP was, if you want files to be protected, they need to be behind your API technology, so if using PHP, it would be a PHP file or route in your PHP API which would deliver the assets. And, in that PHP file/ API route, you’d be using your API’s auth system to verify the user can get the files being called for. Again, not the expert here, but that is my past experience. There is no way I know of to let Apache be aware of any particular access unless you use Apache’s own auth system and that would mean duplication of user credential entry for the users and I highly doubt that is in your or your users’ interest.
Scott
-
There is the rewriteMap directive. With it you can check & modify the URL requested by the client (before being processed) with an external script or executable, and then allow apache to do it’s job as usually. It’s the best way? I don’t know… For me it’s working well for the moment.
You are talking about having only one php file that would redirect you (or not) to the desired content? Something like a php loader?
With PHP API you mean a third-party API or your own writted API? Am I reinventing the wheel?
Regarding to the original question, there is a way that Quasar puts all the content I consider that needs to be protected in a single folder when building the SPA?
Thanks for your time @s-molinari
-
I actually meant a php file that would server the file content. PHP can do that.
Scott
-
I think what you may need is called XSendfile. It works like that:
- Client C sends request to server (S) for specific file.
- S sends this request to the backend B with question what to do with that?
- If C is not authorized/allowed, B sends standard HTTP status code, S proxies this to C, end of story
- If C is authorized, B sends response to S with special header with special INTERNAL redirect.
- S recognizes this header and INTERNALLY redirects to INTERNAL location, which could map to physical, protected and externally inaccessible file (or another redirection).
- C is getting a response with requested file as if it was accessed by original request from #1. Done.
I implemented this many times with nginx/openresty and it works GREAT. This is a recommended way of efficient, cache friendly, secure accessing protected/hidden user files.
More here:
https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/
and here:
https://www.nginx.com/resources/wiki/start/topics/examples/xsendfile/and it seems as Apache has similar technology (but I didn’t tested this personally with Apache):
https://tn123.org/mod_xsendfile/cheers!
-
Thanks for your answers.
I have read about x-sendfile before, maybe I have to reconsider the inner work of the backend.
But either with x-sendfile, readfile(), or rewritemap, there has to be a trigger that tells apache to process the request by the php backend. I think there are three options:
-
Redirect all the requests to a php file that will decide what to do with the request. I think that this is the option that both of you are proposing. The script will check if the user is authorized, but first of all has to check if the requested file is protected or public. So there should be an array of public files in memory, that should be checked in every request to know if the requested file is protected or not. Don’t know if this scalates pretty well.
-
Place all web app (or the private files) outside the public server folder. Place the public files in the public server folder. Tell apache to redirect to the php script when no file can’t be found. The script will search the file in the private folder. This way there is no need to keep a list with the protected files, but for the private ones, two file searches will be needed.
-
Achieve to have the Quasar CLI output in two folders: “./private/…” and “./pubic/…” or “./” All the requests to ./private/… will be redirected first to the php script to check user credentials. I thought that this is the best way because it’s straightforward and fast for apache to know if the file can be served directly or a script needs to be called. But I don’t know if this kind of output can be achieved.
What do you think?
Sorry if this is drifting a little bit offtopic, but it has been useful for me. Thanks for your time,
H25E
-
-
The script will check if the user is authorized, but first of all has to check if the requested file is protected or public.
Um, you can and should make that determination with the image’s URL. That is where the logic should go -> In the depiction of the asset (as it causes new requests) and thus, you can avoid a bit of the bottleneck of having all calls for assets go to a single file.
Don’t redirect, if you don’t have to, is what I would say to point 2.
If you follow what I said above, point 3 becomes moot. You’ll have public files/ assets and you’ll have private files/ assets. Most of the time, private files are either user generated or generated outside of the app, so you don’t need Quasar’s CLI messing with them per se.
Like I said earlier, if the images are part of an app, but the app itself is “private”, like an admin area app, the images can still be public. Well, at least there shouldn’t be content in them that is “private” to the point they need to be hidden. I’m not totally sure of your use case, so I figured I’d make that point too (again, if it wasn’t clear earlier).
Scott
-
Okay, I will take all the info an reconsider certain parts of the project. Thank you so much!!
