You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the issue
Based on the code in https://github.com/architect/functions/blob/master/src/static/index.js, I think that if you deploy to AWS and don't have a domain set up for your app (and thus will have /staging and /production URL path prefixes for all routes), any usage of arc.static without setting the second options argument to {stagePath: true} will yield an incorrect path (missing the first staging or production URL path segment). As far as I can tell, the only way to get arc.static to correctly prefix the stage name is by using this second options argument.
Steps to reproduce
Create a basic arc app with:
a @static pragma
add a static asset under public/, e.g. public/foo.css
a single @http route
have the route use @architect/functions and e.g. print out the path to the static asset via a call to arc.static('foo.css')
make sure no domain is associated to the app
Run it in sandbox and load up the http function: displays the right path (/_static/foo.css).
Deploy it to AWS and load it up: womp womp. You'll get HTTP 403 responses from S3 because the stage URL prefix is missing: blahblahblah.amazonaws.com/_static/foo.css should be blahblahblah.amazonaws.com/staging/_static/foo.css.
Expected behavior
Works in both sandbox and deployed to AWS.
Additional context
The workaround is to call arc.static with an options argument that looks like {stagePath: true}. In sandbox, stagePath will be ignored (as there is logic in arc.static protecting against the local case). When deployed to AWS, it will get used in the path. Feels like this should be default behaviour? Though if I understand correctly, that will mess up apps that have and use a domain. Maybe it's simply a docs issue? Not sure.
The text was updated successfully, but these errors were encountered:
Describe the issue
Based on the code in https://github.com/architect/functions/blob/master/src/static/index.js, I think that if you deploy to AWS and don't have a domain set up for your app (and thus will have
/staging
and/production
URL path prefixes for all routes), any usage ofarc.static
without setting the secondoptions
argument to{stagePath: true}
will yield an incorrect path (missing the first staging or production URL path segment). As far as I can tell, the only way to getarc.static
to correctly prefix the stage name is by using this second options argument.Steps to reproduce
Create a basic arc app with:
@static
pragmapublic/
, e.g.public/foo.css
@http
route@architect/functions
and e.g. print out the path to the static asset via a call toarc.static('foo.css')
Run it in sandbox and load up the http function: displays the right path (
/_static/foo.css
).Deploy it to AWS and load it up: womp womp. You'll get HTTP 403 responses from S3 because the stage URL prefix is missing:
blahblahblah.amazonaws.com/_static/foo.css
should beblahblahblah.amazonaws.com/staging/_static/foo.css
.Expected behavior
Works in both sandbox and deployed to AWS.
Additional context
The workaround is to call
arc.static
with an options argument that looks like{stagePath: true}
. In sandbox,stagePath
will be ignored (as there is logic inarc.static
protecting against the local case). When deployed to AWS, it will get used in the path. Feels like this should be default behaviour? Though if I understand correctly, that will mess up apps that have and use a domain. Maybe it's simply a docs issue? Not sure.The text was updated successfully, but these errors were encountered: