On 18 April 2017 12:18:57 BST, duanyao <duan...@ustc.edu> wrote:
>在 2017年04月18日 18:52, Ashley Sheridan 写道:
>>
>>> Maybe no. "files" is a generic word, so if you make every
>"xxx_files/"
>>> folders magical, it's quite possible that there are folders happen
>to
>>> ends with "_files" but are not intented to be local web apps. If you
>>> require a `xxx.html` to make "xxx_files/" magical, it is a little
>>> awkward and confusing for muli-page app.
>>>
>>> This is why I propose a new (and unlikely already used) pattern
>>> `xxx_webrun/` for more powerful muli-page app, and limit
>`xxx_files/`
>>> to
>>> single page app.
>>>
>>> In single page app case, it would be more common that `test.html`
>gets
>>> `test_files\page{2|3}.html` via XHR and renders the latter in place,
>>> instead of navigating to it.
>>> So the latter don't need to access `test_files\config.json`
>themselves.
>> *any* magic behavior is a sure-fire sign that something is wrong(TM)
>Maybe. But there are occasions where magic is unavoidable. E.g. how to
>infer the MIME type of a file? filename extension? magic numbers? all
>are magic.
>
>If the barrier is not high enough, name it `xxx__webrun__/`.
But when you're talking about security, which we are, relying on magic anything
is potentially disastrous.
You mention mime types and file extensions, both of which are not safe to rely
on for anything related to security, hence there being entire libraries and
frameworks to attempt to determine and test a files real type (windows still
fails abysmally in this area though).
Just relying on magic filenames *will* fail. Consider the scenario where a file
is accidentally copied over the original entry html. Now it's associated with
the wrong directory of assets and other 'linked' files. This new html entry
point file could easily be an exploited file, looking to grab whatever data is
being held locally on your machine.
>
>>
>>
>> Thanks,
>> Ash
Thanks,
Ash
