x)- [x] bug report
- [ ] feature request
@angular/cli: 1.0.4
node: 7.10.0
os: darwin x64
@angular/common: 4.1.3
@angular/compiler: 4.1.3
@angular/core: 4.1.3
@angular/forms: 4.1.3
@angular/http: 4.1.3
@angular/platform-browser: 4.1.3
@angular/platform-browser-dynamic: 4.1.3
@angular/router: 4.1.3
@angular/cli: 1.0.4
@angular/compiler-cli: 4.1.3
When running ng build --prod, query parameters of background-image URLs in my scss file are not maintained in the same order they were.
Original line in scss file:
background: url('https://fnbfb.imgix.net/https%3A%2F%2Ffirebasestorage.googleapis.com%2Fv0%2Fb%2Ffamilinb-web.appspot.com%2Fo%2FUnused%2520-%252054148193_xxl.jpg%3Falt%3Dmedia%26token%3D25f08c08-ed7d-4b3b-a041-4368f8d8d451?auto=format&fit=crop&w=600&h=400&expires=1496488841&s=3bdd3f89855db0ee92aaa2db61f3ffe4')
Line in main.xxx.bundle.js:
background:url(https://fnbfb.imgix.net/https%3A%2F%2Ffirebasestorage.googleapis.com%2Fv0%2Fb%2Ffamilinb-web.appspot.com%2Fo%2FUnused%20-%2054148193_xxl.jpg%3Falt%3Dmedia%26token%3D25f08c08-ed7d-4b3b-a041-4368f8d8d451?auto=format&expires=1496488841&fit=crop&h=400&s=3bdd3f89855db0ee92aaa2db61f3ffe4&w=600)
If the order is not maintained, imgix does not validate the signature. Also, the s parameter has to go in the end.
This seems more like a defect with the signature checking process. Relying on query parameter order doesn't seem like the best idea and the signature validation could be changed to handle order independence.
Thank you; but since I do not at all control this service, would you suggest a workaround for it for the moment?
I don't have a workaround for this at the moment. We don't manipulate those directly so perhaps it's part of node-sass processing... there might be a workaround there.
By the way, I've reached out to the service provider, and here's the response I got:
The Secure URL feature performs a very specific function that I'd be happy to clarify. A key is generated and added with the s=$STRING present in the query string, and this string is unique to the URL configuration. After all, the Secure URL feature is meant to stop other users from altering the query string, and by extension, the values of your parameters. If any change is made to the query string, like rearranging the parameters, a 401 response will be outputted. This explain the behavior you're seeing. I've spoken with our team, and they've informed me that we don't have any current plans to change this functionality. You'll need to generate a signature with the URL you're expecting to serve, or turn off the feature entirely if you find the downsides are not worth the security offering.
To be fair, this sounds pretty logical to me.
Well, it is being suggested that this would be the culprit:
https://www.npmjs.com/package/query-string
.stringify(object, [options])
Stringify an object into a query string, sorting the keys.
That's very useful info @picosam, thank you and @mgreter for looking into that!
If indeed query-string is the culprit, then it seems to be happening as part of cssnano:
kamik@T460p MINGW64 /d/work/angular-cli (master)
$ npm ls query-string
@angular/[email protected] D:\work\angular-cli
`-- [email protected]
`-- [email protected]
`-- [email protected]
`-- [email protected]
This makes sense. We only minimize CSS in --prod. It looks like it's the normalizeUrls options in http://cssnano.co/optimisations/.
I agree that your usecase is sensible. Would you like to submit a PR to disable that optimization in that set of options? I'd ask you to add a comment there pointing to this thread, and also to add a test in https://github.com/angular/angular-cli/blob/master/tests/e2e/tests/build/styles/postcss.ts.
https://github.com/angular/angular-cli#development-hints-for-working-on-angular-cli contains pretty much all the info you need to use the master branch locally. You can modify that option and verify it works in your project by linking.
I've created projects that used similar secure URLs (basically hashing the querystring against a private key), and the key to making it work is that the querystring is in a predictable order at both ends of the chain. I decided early that parameters would be alphabetized before being hashed because I have no way of controlling how they come in or in what order. A proxy could easily mess with them, for example, or even add parameters if it wanted.
IMHO, the maintainer of that library should enforce a predictable order on the hashing - alphabetizing the parameters should be done first on both the client and server ends :) Then no problems with minifiers and optimizers!
@filipesilva This no longer happens in 1.7+
This no longer happens in 1.7 (currently in beta). But fixed is really the inappropriate word. As explained above and more completely by @metaloha , this is really an issue with the service being used and not the act of alphabetizing or otherwise sorting the parameters. Note also that a future optimizer/minifier could be used that again does so.
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
_This action has been performed automatically by a bot._