To sketch out my problem: We have an angular app, which is served by basic auth protected server. This app is supposed to run among others in IE11 and Safari 12. And we have differential build to cover for es5 and es2015+ environments.
Now when it comes to build-produced index.html, Safari 12 needs to have crossorigin attribute on <script type="module"> there in order to send BA credentials to the BA-protected server (although the client and server domain match). Without the attribute, it doesn't send them and the request fails with 401. It turns out, that some older browsers, like Safari 12, implement older version of spec for type=module script fetching, which doesn't send the auth credentials automatically. Newer browsers implement newer version of the spec and the credentials are sent correctly (that's why Safari 13 works for me).
So my fix for this issue was to set crossorigin="anonymous" attribute via angular.json. This causes every build to produce <script>s for both es5 and es2015 bundles with this attribute, which fixed the issue in Safari 12. So far so good.
But then I discovered, that IE11 doesn't handle this attribute well. In fact, the crossorigin attr is not supported in IE11, which shouldn't make a difference, but it doesn't send the credentials when sending request for script, regardless of its type="", which naturally fails with 401 again. When I remove the crossorigin attribute, it fixes the issue in IE11, but guess what, breaks Safari 12 again.
With all that in mind, the logical solution would be to add crossorigin only to es2015 scripts (for Safari 12) and leave es5 scripts intact (for IE11). This is more difficult than it sounds though, because as it seems, angular-cli doesn't have the option to distinguish based on ES target. It just provides an option to set crossorigin on all produced scripts.
And this is where the actual questions come in:
Is there an easy way to do this with angular-cli? Outside of writing some kind of a node script that does this for me.
Am I perhaps approaching this problem from a wrong angle? Is there a better way to solve this credential sending problem?
And bonus question: Why isn't IE11 able to handle the (for it) unknown crossorigin attribute? I thought unknown attributes are just ignored.
Related
I am totally lost, don't even know what to google anymore, maybe someone can push me in the right direction here:
I have a WildFly Server running, and I did some changes to a JavaScript file.
As soon as I republished the new .war file to the server, the changes caused by the new js file were visible in my browser on the computer.
Yet, as I opened my phone to check the results there, nothing happened. I cleared the cache and, of course, now the changes appeared. On both, computer and phone, I was using Chrome.
I put the HTTP Header "Cache-Control" with "no-cache" as value, but that didn't do anything.
I use NGINX in front of the WildFly, but I checked and NGINX does not filter out that header.
I also tried versioning the files. WildFly offers a very neat solution for that, if you stumble across this question, check out this post to see how that is done. But this didn't do the trick for me either.
Does anybody know what might be going on here?
Thanks for any help or comments!
It ended up being a timing issue.
The browsers on the phones eventually reloaded the current files, and since then changes are visible immediately.
The script trick with the version number works like a charm. So do the headers ("Cache-Control: no-cache"). Both together are probably pretty fail safe. One can't do it all with version numbers, only the includes.
Thanks #Azametzin for the input!
If the cache cleaning through "Cache-Control" is failing somehow, another solution would be to set a new version for JavaScript file. For example:
<script type="text/javascript" src="script.js?v=0.01"> // any version number you want
I'm not very used to WildFly Server, but I believe you could set a function for creating a random number that will be used as the new version everytime the page is refreshed.
Something like: <script type="text/javascript" src="script.js?v={random number here}">
Hope it gives you a direction to follow.
Not all browser which cache-control supports in some browsers in Android device (Not Chrome Android), because the cache-control still works in android device. Some browser which taken from Android doesn't work.
I have a download link like so:
Foobar
This works fine when downloading a file on the same server, but when downloading from another server (Azure blob storage in this case) the filename stays as "foo.xls", even though the HTTP response comes back with the following header:
Access-Control-Allow-Origin: *
Is this by design or is there potentially another header I can to add to the HTTP response to get this to work?
Yes, it is by design that the CORS headers have no affect on the download attribute. There are only two browsers that support the download attribute, Firefox and Chrome, and both browsers have a different policy on cross-origin files.
Chrome versions prior to 65 actually did allow the download attribute on cross-origin files, without CORS headers, but Firefox chose not to, citing potential social-engineering attacks.
MDN documents this behavior for Firefox 20 under the download attribute section for the a tag, behavior that has not changed since.
In Firefox 20 this attribute is only honored for links to resources with the same-origin.
This Bugzilla report discussed the security concerns and the possibility of using CORS.
When the user clicks such a link, the user will be prompted if they
want to download. It seems very easy for the user to make the mistake
of thinking that something on the original website is being
downloaded, and not something from bank.com.
Would it be possible to implement it with same-origin and CORS
(Access-Control-Allow-Origin) in mind if you are questioning cross origin
security? This is very useful feature for web applications (create Blob
using JS and let user download it with some meaningful name)
Google was opposed to using CORS for this.
There's also this Bugzilla report, which summarizes their decision from the other bug report.
Also, cross origin downloads are working perfectly in Google Chrome.
Yes, and we think they're adding security bugs by doing that.
The Bugzilla issues don't seem to rule-out the possibility of using CORS for cross-origin download attribute support in the future, but right now using CORS headers does not do anything for the download attribute. It's possible that if other browsers start supporting the attribute, a consensus may yet be reached.
For sake of completeness, there is of course the Content-Disposition header which you can use to force a download from the other domain, but this does not provide the same functionality as the download attribute. It does have better browser support though.
I am attempting to use the HTML5 method 'postMessage'. I know this method only works in 'modern' browsers, but for my customer base, that is good enough.
Here is my situation:
A browser window on domain 'abc.com' opens a new window on domain 'xyz.com'. I own both domains, and I can put any javascript I need to on either side. From what I can tell, I should be able to use 'postMessage' to send messages between the two windows. This works in Chrome, but not in IE 9. I am unable to get a reference to the parent window from the child or vice-versa. If both windows are on the same domain, I do not have a problem.
So, is this a bug ("feature") of IE's implementation of 'postMessage'? Is there any way I can accomplish what I am trying to do?
Many thanks!
Unfortunately, IE's postMessage implementation only works between windows and iframes and frames. Trying it with a window.open will result in a No such interface error when postMessage is called, even though the debugger clearly shows the method existing.
Does anyone know how to setup kaazing websockets for use with IE and firefox? My app works great in Safari and Chrome but I can't get it to work with these two browsers. It just gives me a WebSocket is not defined error.
According to their website, I thought all you needed was to add:
<head>
<meta name="kaazing:postMessageBridgeURL"
content="http://www.example.com/bridge/PostMessageBridge.html" >
</head>
But I put the file there and still, it is failing.
You only need that tag you mentioned if you intend to do cross-origin connectivity in IE6 and IE7.
But if you just want basic WebSocket to work in those browsers the thing you need to do is include the WebSocket.js or ByteSocket.js files. In summary, if you intend to use text messages, then put this in your HTML page:
<script src="/html5/WebSocket.js"></script>
If you intend to use binary messages, then do this instead:
<script src="/html5/ByteSocket.js"></script>
This is more fully explained in the documentation here for typical usages of WebSocket:
https://kaazing.com/getting-started/
Regards,
Robin Zimmermann
Kaazing Product Management
Which version of the gateway are you using?
The step you mentioned is only required if you are integrating with another web server (like Apache). Is that what you're doing?
Is anyone aware of whether it is problematic to use protocol relative URLs for an image source to prevent mixed content security warnings.
For example linking an image like:
<img src="//domain.com/img.jpg" />
instead of:
<img src="http://domain.com/img.jpg" />
or
<img src="https//domain.com/img.jpg" />
In my testing i've not seen anything to suggest this is wrong but i'm not sure if it has edge cases where it will create problems.
EDIT i've seen it throw errors when using PHP's getimagesize function.
Found an interesting gotcha for the use of protocol relative URLs:
You have to be careful to only use
this syntax in pages destined for
browsers. If you put it in an email,
there will be no base page URL to use
in resolving the relative URL. In
Outlook at least, this URL will be
interpreted as a Windows network file,
not what you intended.
from here
Essentially though there are no valid reasons why this shouldn't work as long as the request is made by a browser and not an external email client.
more info from here:
A relative URL without a scheme (http:
or https:) is valid, per RTF 3986:
Section 4.2. If a client chokes on it,
then it's the client's fault because
they're not complying with the URI
syntax specified in the RFC.
Your example is valid and should work.
I've used that relative URL method
myself on heavily trafficked sites and
have had zero complaints. Also, we
test our sites in Firefox, Safari,
IE6, IE7 and Opera. These browsers all
understand that URL format
IE 7 and IE 8 will download stylesheets twice if you're using a protocol-relative URL. That won't affect you if you only use it "for an image source", but just in case.
The following should be considered when using Protocol-Relative URLs:
1) All modern browsers support this feature.
2) We have to be sure that the requested resource is accessible over both HTTP and HTTPS. If HTTP redirects to HTTPS it is fine, but here the load time will take a little longer than if the request was made directly to the HTTPS.
3) Internet Explorer 6 does not support this feature.
4) Internet Explorer 7 and 8 support the feature, but they will download a stylesheet twice if protocol-relative URLs are used for the css files.