Invalid path error creating directory?

Wappler General How To
#21

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…

#22

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.

#23

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
#24

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 :slight_smile:

1 Like
#25

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!

#26

@sitestreet bang on!

:slight_smile:

1 Like
#27

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
#28

Sounds perfect @patrick. That would work for us in the vast majority of circumstances we encounter. Thank you for your considerations.

#29

@patrick @George @Teodor

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…

:smiley:

1 Like
#30

I hope the team realise the above is both an acknowledgement of my own inadequacies and a joke on myself! :blush:

#31
#32

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.