Bump, sorry, desperately required! Not being able to traverse outside the Project root restricts so much.
Couldn‘t you create a custom module?
Good idea but really should not be necessary. Its a basic ability that should not require custom modules. Besides I just wouldn’t have a clue where to start to be honest… Really would like to be able to do this natively within Wappler through the UI and Server Connect.
Please @George @Teodor @patrick
Could you please consider allowing us to navigate out of the Project root directory. This is now becoming a real issue and restriction with multiple Projects. We can’t tell the Clients sorry you need to change your structure and move tb’s of images… The majority of Clients have media stored outside of Project roots and as we are going through them and updating their deployments we keep hitting this wall repeatedly…
Its so bad if anyone would like to create a custom module for us ASAP we are more than happy to pay you! We are desperate to resolve this issue.
Thanks.
I will see if I can make it work, which server model are you using and which modules/actions require a full path?
2 Likes
I know how busy you are so this is very appreciated @patrick
Server model is straight forward PHP.
File Management:
Create Folder
File Upload
File Remove
Image Processor:
Load Image
Re-Size Image
Store Image
Thank you so much for anything you can do. Always sincerely appreciated.
Please is there any chance of implementing the ability to select paths outside of the app root as working with two Projects, Mobile scenario, it renders all the file actions (and associated actions for file and folder manipulation etc) obsolete. It really is essential and required. Now becoming very urgent indeed.
Well it is not that easy Dave. Storing anything outside your project root, done by web users is a great security risk.
If the correct checks aren’t performed you risk overwriting system files and getting hacked.
Also so many people select bad locations outside of the project just by mistake, thinking we will be auto including those files to the project.
That is why we are even thinking to use a custom limited files selector from the project folder only (like the assets manager) as file and folder picker instead of the system one, to prevent such mistakes.
Is it not for the user to decide though George? I appreciate the response of course. For those that select bad locations its the same as them just bolting on any library just because it does something they need, a recent discussion recently highlighted that fact and risk, but Wappler doesn’t stop them using npm does it… Or the Terminal, or for that matter any number of other routes to disaster you care to pick from.
This relates to so many factors out of Wapplers control. I’m not about to do that, and would appreciate a further explanation of what you are suggesting here? Someones going to overwrite their root folder or delete win32.sys (joke)? Surely that is for the developer to think about and not Wappler? The BIG problem is if anybody wants to use two Projects essentially all those amazing server side components are void and useless. Doesn’t make any sense to me at all? Too many restrictions imposed by Wappler will do more harm than good for most users, in my opinion. I don’t feel it is Wapplers job to babysit bad developers, but then I’m not the Co-Founder or a team member so that really is not my choice. Just very disappointed the same old case of the ‘what if and maybe’ scenario holds the rest of us back…
So what is Patrick suggesting? He is very aware of consequences and his ability is unquestionable. So why would he suggest he could make it work if you are saying it would lead to compromise and disaster? Which page are we on?
Maybe like the Server Connect Debug option tuck the option away to set alternative paths? Just a suggestion! I’m not being an ar5ehole here just failing to understand the logic when there are so many other ways for users to FUBAR their applications or open them up to unwanted activity.
What kind of paths would you like to use. Full paths anywhere on the system or are just relative paths enough to access files just above the project root.
1 Like
For me, being able to upload files to the parent folder of the webroot would be ideal (and sub-folders of that) so somewhere like ../uploads to effectively be at /home/uploads (as apposed to /home/public_html/uploads). I don’t think I’ll ever need to go anywhere else in the filesystem.
Hope that makes sense! In short, relative paths please 
1 Like
Hi Patrick thanks for your reply. We don’t require full paths although if it makes more sense to do this then it would be great. Often we encounter Projects where applications/sites are nested within directories, or have pre-configured directories for images/media/etc. All within the home directory of the site. In this case relative paths allowing us to escape the confines of the Project directory would suffice. An example:
public_html
- images
- lrg
- sml
- Project1
- dmx etc
- Project2
- example
So we want to grab images in Project1 but can’t in the current configuration. We rarely work with full paths outside of internally for other Projects on our servers away from the public. Just being able to escape the Project root itself would be a real game changer and avoid us using symlinks which inherently have lots of consequences and are easily forgotten about. We are perfectly capable of doing this but in all honesty we hate using symlinks for lots of reasons.
I hope that makes sense. Truly appreciate your thoughts as always, and those of George too! I’m not discounting George and I love his care for the user and his concerns, all of which do make sense. Just babysitting too many factors is detrimental to dare I say it ‘power users’ who will leverage all Wappler has to offer in amazing ways, and share with the users how they do these things. I’m sure if any of us spot anything dangerous going on with a users ideas we’ll all be quick and kind enough to point out any issues that could arise.
Thanks again!
A path like /home/uploads could probably a bit problematic with our current implementation, because we see paths starting with a / as application path which is relative to the root of the project. We could have relative paths with ../ which is also relative from the root of the project, but would allow you to go outside of it. For full system paths we could perhaps support URIs, like file:///home/uploads.
2 Likes
Sounds perfect @patrick. That would work for us in the vast majority of circumstances we encounter. Thank you for your considerations.
Come on guys! You could have at least said ‘Dave you plonker why don’t you use the S3 Connector and offload all that bulk to Amazon!’… But NO you thought about helping me instead! You’re just too polite gentleman…
1 Like
I hope the team realise the above is both an acknowledgement of my own inadequacies and a joke on myself! 
Is there any update to this? It’s one of the most basic ways to secure images/files for websites that aren’t public and where the images shouldn’t be accessible via a URL. While it’s possible via .htacess, that is vulnerable to spoofing.