feat: SPA routing fallback support #491
Conversation
lifeart
force-pushed
the
improve-routing
branch
from
4647607 to
a375bdc
Compare
lifeart
force-pushed
the
improve-routing
branch
from
ae5500a to
71e1f03
Compare
| @@ -27,6 +27,16 @@ interface MiddlewareOptions { | |||
| liveReloadPath?: string; | |||
| } | |||
|
|
|||
| function findClosestIndexFileForPath(outputPath: string, prefix: string): string | undefined { | |||
There was a problem hiding this comment.
Path manipulation from inbound requests always gives me the heebeegeebeez do to the potential of path traversal security issues. I would prefer to avoid as much liability here as possible. Do we think the fallback index.html lookup is something sufficiently commonly used to justify?
Or would a fixed index.html such as https://github.com/ember-cli/ember-cli/blob/2d77f099c19f2b54328e7e961e0b23a31a638661/lib/tasks/server/middleware/history-support/index.js#L63 be sufficient.
I can be convinced by either approach, the former will just require substantially more testing and care.
There was a problem hiding this comment.
@stefanpenner we could skip index search if path contain . to prevent traversal security issues.
I seen cases where multiple static apps composed into one using nesting (and have to deal with it):
root_app
/child-app
/some-side-app
/help-appThere was a problem hiding this comment.
Ya it’s not a bad feature at all.
There was a problem hiding this comment.
@stefanpenner added guard for . in path 99b5a32#diff-92fc8ac710621cc64e5b3683c8c56bf5aec7a209c2968a1818bab04b11551811R87 and improved tests
resolves: #425
broccoli server able to detect
index.htmlfiles on path requests like/foo->/foo/index.htmland return it.But, If we use livereload and js-based app navigation, broccoli don't drill down to root
index.htmlfor requests like:/foo/bar-> current lookup:
foo/bar/index.html,404-> expected lookup:
/foo/bar/index.html,/foo/index.html,index.html,404