Re: [ValidateThis] File Permissions error in Shared Hosting (#74)

[John Whish]

Hi Greg,

Doesn't this mean that if the host doesn't allow file access then no
validation will work? Hmmm, I think I'd rather VT threw an error than
completely ignored the file (even though it exists). I guess
annotations would still work.

- John

On 19 January 2012 17:19, Greg Moser
<reply+i-2900450-8a17b98312be031...@reply.github.com>
wrote:
> There is a file Permissions issue on Shared Hosting.  We addressed it in Slatwall by making this change to ValidateThis:
>
> https://github.com/ten24/Slatwall/commit/1f27f4bcdf7ffaf32d0126209e5792c61adc9753
>
> -Greg
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/ValidateThis/ValidateThis/issues/74

[Bob Silverberg]

Good point John. Is this something that could be rewritten to use
Java to check for file existence, rather than CF's FileExists? Or
would that still have the same problem?

Greg, are you guys exclusively using annotations for validations?

Bob

> --
> You received this message because you are subscribed to the Google Groups "ValidateThis-dev" group.
> To post to this group, send email to validate...@googlegroups.com.
> To unsubscribe from this group, send email to validatethis-d...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/validatethis-dev?hl=en.
>

--
Bob Silverberg
www.silverwareconsulting.com

[John Whish]

I've not used many shared hosting companies, but when I have, if you'd
asked them to enable cffile then they would if you could give a reason
why you needed it, so I personally don't think we should be coding
around restrictive hosting environements.

I'm curious to know if the user that reported this to Greg was able to
upload images via slatwall/Mura (assuming that those images aren't
stored in the database)

On 20 January 2012 15:10, Jamie Krug <ja...@thekrugs.com> wrote:
> It probably depends upon the shared hosting company, but if they've
> disallowed CF file system functions they've likely also disallowed creating
> Java objects via CF. To not even have read-only access to the file system
> will obviously be extremely restrictive to a lot of CF apps :(

[Sumit Verma]

It's not an issue when the file path is inside application root. I have not seen any shared host block file access inside app root. Issue comes up only when for some reason the validation looks for a path that doesn't exist or is deeper than app root. 

I think failing silently makes sense here because validateThis could not find any file in that path that it can perform validation based on. 

The error is actually thrown from Java not having access to that path.

Sumit Verma
Partner / Vice President | ten24, LLC
office: 877.886.5806 x 103 | mobile: 617.290.8214
www.ten24web.com | www.linkedin.com/in/sverma | twitter: blogonria

On Fri, Jan 20, 2012 at 9:24 AM, Bob Silverberg <bob.sil...@gmail.com> wrote:

[Jamie Krug]

It probably depends upon the shared hosting company, but if they've disallowed CF file system functions they've likely also disallowed creating Java objects via CF. To not even have read-only access to the file system will obviously be extremely restrictive to a lot of CF apps :(

On Fri, Jan 20, 2012 at 9:24 AM, Bob Silverberg <bob.sil...@gmail.com> wrote:

[Matt Quackenbush]

I have to agree with John here. 200%.

I am assuming that the file being outside the webroot is just one folder above the webroot, but within the user's FTP root. Any host that denies access to that should be shot, and certainly is not worth hosting with. It is absurd to not give the user access to his/her directory structure. (Obviously this does not apply if trying to access somewhere else on the server, but knowing Greg and Tony (and having met Sumit), I'm pretty damn confident that Slatwall does not do anything untoward like try to access and modify files that should be secured. :-)

/.02

[Sumit Verma]

Hey Guys,

The error comes up on a path that we certainly don't use. Also, it shows up in addition to the valid path that works fine. We can't reproduce this on our systems. You can look up 2 error stacks here: 

http://groups.google.com/group/slatwallecommerce/browse_thread/thread/bc1f49d5563e5cbf?pli=1

http://groups.google.com/group/slatwallecommerce/browse_thread/thread/4b34525d2228e9ac/93ebbf8e7a4af9f5?lnk=gst&q=filepermission#93ebbf8e7a4af9f5

So, obviously the error is also related to path being wrong somewhere, somehow, we just can't figure out. 

Thanks,

Sumit

Sumit Verma
Partner / Vice President | ten24, LLC
office: 877.886.5806 x 103 | mobile: 617.290.8214
www.ten24web.com | www.linkedin.com/in/sverma | twitter: blogonria

[Bob Silverberg]

Thanks for the info, Sumit. Based on where this discussion has led,
it does sound like we need to sort out why an invalid path is being
searched, rather than make a code change to cover up what is likely a
bug.

I'll take a look at those and hopefully be able to figure something out.

Bob

[Greg Moser]

Hey guys i appologize for not chiming in sooner ( didn't know this thread was happening ). First i agree that our try / catch was a band-aid at best. I also agree that it seems like the underlying issue is that VT is checking an invalid path in the first place. With that being said, i can do some more digging on how/why this is getting called in the first place and if there is anything that makes it happen because of our specific configuration of VT.

[Bob Silverberg]

That would be great Greg. I haven't found the time to look into it
yet, so any more info you could provide will be very helpful.

Bob

On Sat, Jan 28, 2012 at 10:53 AM, Greg Moser <gregj...@gmail.com> wrote:
> Hey guys i appologize for not chiming in sooner ( didn't know this thread was happening ).  First i agree that our try / catch was a band-aid at best.  I also agree that it seems like the underlying issue is that VT is checking an invalid path in the first place.  With that being said, i can do some more digging on how/why this is getting called in the first place and if there is anything that makes it happen because of our specific configuration of VT.
>

> --
> You received this message because you are subscribed to the Google Groups "ValidateThis-dev" group.

> To view this discussion on the web visit https://groups.google.com/d/msg/validatethis-dev/-/YKwtcPRJa6IJ.

[Bob Silverberg]

Hi Greg,

Have you been able to look into this any more? I am thinking about
pushing out a version of VT soon and it would be nice to get this
addressed. Do you think you can find some time soon to look into this
and give me some more details?

Thanks,
Bob

On Sat, Jan 28, 2012 at 10:53 AM, Greg Moser <gregj...@gmail.com> wrote:

> Hey guys i appologize for not chiming in sooner ( didn't know this thread was happening ).  First i agree that our try / catch was a band-aid at best.  I also agree that it seems like the underlying issue is that VT is checking an invalid path in the first place.  With that being said, i can do some more digging on how/why this is getting called in the first place and if there is anything that makes it happen because of our specific configuration of VT.
>

> --
> You received this message because you are subscribed to the Google Groups "ValidateThis-dev" group.

> To view this discussion on the web visit https://groups.google.com/d/msg/validatethis-dev/-/YKwtcPRJa6IJ.

[Greg Moser]

Hey Bob,

Sorry but I have not had time yet.  I've been on super crunch trying to get to a go live by the end of this month.  I guess it'll have to wait another release cycle.

-Greg

[Bob Silverberg]

Hi Greg and Sumit,

I am finally getting around to looking into this, and what I can see
from the trace is that VT is trying to see if a file exists in
\Slatwall\com\validation\Slatwall\com\entity\, specifically the file
Brand.xml. Is there a cfc in that folder called Brand.cfc? If so, VT
will look for an xml file with a corresponding name, so this makes
sense.

I need to know a bit more about the configuration to understand what
the problem is. Can you show me the VT configuration, and also the
folder structure for where Brand.cfc is located?

Thanks,
Bob

> --
> You received this message because you are subscribed to the Google Groups
> "ValidateThis-dev" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/validatethis-dev/-/TBRHSbHKmRQJ.

[Sumit Verma]

Hi Bob,

The folder where VT is looking doesn't even exists and not defined in config as well. We can't replicate so, not sure what's going on. You can look at VT setup here:

Line 145: https://github.com/ten24/Slatwall/blob/master/Application.cfc

Entity is in : \Slatwall\com\entity

Validation is in : \Slatwall\com\validation

Thanks,

Sumit

Sumit Verma
Partner / Vice President | ten24, LLC
office: 877.886.5806 x 103 | mobile: 617.290.8214
www.ten24web.com | www.linkedin.com/in/sverma | twitter: blogonria

[Bob Silverberg]

It seems like what's going on here is that it's taking the
definitionPath, which is defined as "/Slatwall/com/validation/" in
your config, and then appending the path to the component to it. I
have a feeling that this is happening in the getAbsolutePath() method
in FileSystem.cfc, but I cannot recreate it either. Is there any way
you can run a test on one of the servers that is encountering this
issue, where you pass different values into that method and see what
gets spit out?

Another approach would be to add some debugging code into the
locateRulesFile() method, which is in ExternalFileReader.cfc, to see
what definitionPath and defPath are throughout the execution.
Something funny is happening in there.

Do you think there's any chance that can be done on a machine where
this problem is occurring?

Thanks,
Bob

--
Bob Silverberg
www.silverwareconsulting.com

[Sumit Verma]

Hi Bob,

I will ask the user who reported it to try this.

Thanks,

Sumit

Sumit Verma
Partner / Vice President | ten24, LLC
office: 877.886.5806 x 103 | mobile: 617.290.8214
www.ten24web.com | www.linkedin.com/in/sverma | twitter: blogonria