Avoiding CORS


  • Discourse touched me in a no-no place

    This isn't actually "coding help", it's "configuration help", but we don't have that category.

    My company licensed a third-party web application we're trying to integrate into our own web application. We're trying to do this buy stuffing it into an iframe in a page, which is what they more or less said to do, but they're not overly helpful with documentation.

    Our web app is a typical 3-frame thing. You click a function in the left-hand menu frame, it opens in the right-hand content pane. So I added a menu item that loads a page with an iframe, and set the src attribute on the iframe. Where it gets complicated is that our app is on IIS and the other one runs in Tomcat. Right now the two web servers are on different machines but we're going to set up a new server that runs both web servers. As far as I can tell, though, that will still violate the same-origin policy. Before I generate the page with the iframe, on the server I send some XML to Tomcat via server-side AJAX, and get back a token that I turn into a URL, which becomes the iframe src. That initiates the Tomcat application, which then runs in the iframe until the user has finished the process. When they hit a "I'm done" button, the Tomcat app sends XML back to a URL of my choice, which currently is a URL on IIS.

    It looks like the Tomcat Connector is the solution here, but has anyone ever gotten that to work? The instructions were written by someone who thought he was a standup comedian, who isn't good at documentation, and whose first language is probably not English. Has anyone seen better docs? I haven't been searching long yet but I haven't found anything that clearly explains the setup process yet.

    Am I even right that Tomcat Connector is the way to go? It looks to me like the idea is that it runs in IIS as and sort of acts like a transparent tunnel/proxy so the browser doesn't realize it's talking to another web server.

    CORS is getting in the way, and IT doesn't want to enable it, which I'm OK with if there's a better way to engineer this process, but it's the first time I've done anything like this. I was alternatively thinking of having the Tomcat app post to a servlet that would open a JDBC connection back to the database to save the data that way, but I'd rather not do that if I can post back into IIS.



  • @FrostCat said:

    As far as I can tell, though, that will still violate the same-origin policy.

    Depends on whether the frames (iframes or otherwise) have the same origin or not. If you have full control over the server, you might be able to host the third-party web app on the same domain as the other app, then there are no same-origin problems.

    That would be my recommendation.

    Otherwise, there are two ways to communicate cross-domain using AJAX-- CORS and JSONP. CORS is more secure.


  • Discourse touched me in a no-no place

    the topmost document, the one with the frameset in it, will come from http://server:80[1] (IIS). All three frames under that frameset come from the same server. The iframe inside the content frame will look like this: <iframe ... src="http://server:8080/some-url">, and the content is served by Tomcat. I think that makes them not be the same origin, because the port differs? I got the idea that the Tomcat connector lets me get around that in a way I'm not entirely sure, because I haven't gotten it working yet.

    Both web servers, it looks like, are going to be hosted on the same machine/VM, but obviously have to be on different ports. I think that will force them to be different origins, won't it? I read a bit on wikipedia about using javascript to set the domain on one page to be the same as the other, I don't know if that works, but it's almost certainly something I won't be able to do anyway, because the Tomcat application is a black box I can't make any changes to.

    The genii in IT don't want to enable CORS because they think it's not safe. AFAICT, if I restrict the two servers so they will only accept CORS requests from each other, and maybe lock down the method and path, it should be as safe as it gets. The problem is I don't know if I'm going to be able to change their minds.

    [1] Actually we're going to use HTTPS in production but that's not set up yet.



  • Can you use nginx as a proxy and make everything look like it's coming from the same machine?

    Also, I kinda TL;DR'd most of that so sorry if this has nothing to do with anything.


  • Discourse touched me in a no-no place

    @mott555 said:

    Can you use nginx as a proxy

    Does nginx work on Windows? I've heard of it but never used it--in any event it's another component to learn and integrate into the mix.

    My thought was that the Tomcat Connector would perform that function but the documentation is [insert OSS rant here].



  • I'm not sure. I have an nginx server but it's a dedicated Linux VM. It lets me combine a few different servers on different ports and make them all seem to come from a common origin.

    Setup was fairly easy, except for figuring out how to proxy websockets.



  • @FrostCat said:

    I think that makes them not be the same origin, because the port differs?

    Correct.

    You might be able to solve this with some IIS redirect voodoo. (I think the Googling keyword here is "reverse proxy?")

    @FrostCat said:

    I read a bit on wikipedia about using javascript to set the domain on one page to be the same as the other, I don't know if that works, but it's almost certainly something I won't be able to do anyway, because the Tomcat application is a black box I can't make any changes to.

    Same-origin policy goes deeper than JavaScript. There's nothing in JavaScript you can do to bridge it short of using JSONP. Which is insecure.

    @FrostCat said:

    The genii in IT don't want to enable CORS because they think it's not safe.

    Since enabling it requires the consent of the owners of both servers, it's just as safe as setting up the server in the first place. JSONP, on the other hand, once you enable it, literally anybody, anywhere, can access your API.

    @mott555 said:

    Can you use nginx as a proxy

    Adding a third web server into the mix is crazy-talk.

    You can't touch the Tomcat configuration, so that leaves re-configuring IIS to reverse-proxy some subdirectory of your site to the Tomcat site. Which should be fairly easy to do, I just haven't done it personally before.


  • Discourse touched me in a no-no place

    I wouldn't be the one to set it up anyway, but the people who would are already overbusy.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    Since enabling it requires both servers to be under the control of the same person, it's just as safe as setting up the server in the first place.

    I'd be having this argument with a guy who derailed a discussion about introducing source control into the company with the argument that since no product out there would do "everything we need" it would make more sense to write our own and who sees hackers under the bed, unfortunately. Probably the only way we'll allow CORS is if there's provably no other way to do it.



  • Which requests are being blocked by CORS? I'm guessing it's the token request since you're sending some xml, in which case you may need to change your request type to application/x-www-form-urlencoded


  • Discourse touched me in a no-no place

    @blakeyrat said:

    that leaves re-configuring IIS to reverse-proxy some subdirectory of your site to the Tomcat site. Which should be fairly easy to do, I just haven't done it personally before.

    As I hope I made clear, I thought the tomcat connector does that. If not I'll have to figure out how to do it.


  • Discourse touched me in a no-no place

    @rad131304 said:

    Which requests are being blocked by CORS? I'm guessing it's the token request since you're sending some xml, in which case you may need to change your request type to application/x-www-form-urlencoded

    One in each direction: the token request that initiates a tomcat-app session, and when that is done, a POST back to IIS to save the results.

    I cannot change the request type in either direction[1]: the tomcat app is essentially a black box. It takes a POST with an XML body to start the session, and it outputs another POST with XML body.

    [1] Exotic alternatives involving writing a servlet to do that for me aside, but then I'd have to add figuring out how to do that to my plate.



  • @FrostCat said:

    One in each direction: the token request that initiates a tomcat-app session, and when that is done, a POST back to IIS to save the results.

    I cannot change the request type in either direction[1]: the tomcat app is essentially a black box. It takes a POST with an XML body to start the session, and it outputs another POST with XML body.

    [1] Exotic alternatives involving writing a servlet to do that for me aside, but then I'd have to add figuring out how to do that to my plate.

    I meant that changing the request-type header to application/x-www-form-urlencoded sometimes fixes the issue. I didn't mean to suggest you change the content body. This content-type won't trigger a CORS preflight request per: http://www.w3.org/TR/cors/#simple-header

    Edit: text/plain might also work for your purposes, too.



  • @FrostCat said:

    One in each direction: the token request that initiates a tomcat-app session, and when that is done, a POST back to IIS to save the results.

    I cannot change the request type in either direction[1]: the tomcat app is essentially a black box. It takes a POST with an XML body to start the session, and it outputs another POST with XML body.

    [1] Exotic alternatives involving writing a servlet to do that for me aside, but then I'd have to add figuring out how to do that to my plate.

    As far as your IIS app, since you have control there, I'd suggest just setting your access-control-allow-origin to have server:8080 or whatever the source is - you can set it in your app's web.config it's pretty painless and won't compromise your security.

    Edit: go here for the relevant code



  • I've dealt with this in the past - different port numbers on the same host is definitely CORS.

    Also note in my experiments chrome outright refused to do anything CORS-like if nonstandard ports were involved.


  • Discourse touched me in a no-no place

    @rad131304 said:

    I meant that changing the request-type header to application/x-www-form-urlencoded sometimes fixes the issue. I didn't mean to suggest you change the content body.

    Ah. Well, I can look into that. It would be lying, because that's not what the actual content type is, but maybe that's OK?

    I finally got Tomcat Connector to work. I somehow misread what one setting was supposed to be. Someone should tell these guys that if you have to have a setting be a specific value, there's not any real point in having it be something you could set and potentially get wrong. Just suck it up and accept you've got a magic constant. (For future reference: the extension_uri property is NOT the path to isapi_redirect.dll, it's the string "/jakarta/isapi_redirect.dll".)


  • Discourse touched me in a no-no place

    @rad131304 said:

    As far as your IIS app, since you have control there, I'd suggest just setting your access-control-allow-origin to have server:8080 or whatever the source is - you can set it in your app's web.config it's pretty painless and won't compromise your security.

    I tried to do that. The genius I mentioned above more or less flat-out refused to countenance the concept of enabling CORS.

    It looks like the tomcat connector will work for me--I am in the process of testing it right now. It's agonizingly slow on my PC: loading the first block of css/js/html at tomcat app session initiation is taking over a minute.


  • Discourse touched me in a no-no place

    @PleegWat said:

    I've dealt with this in the past - different port numbers on the same host is definitely CORS.

    Yup. As I said, the TC seems to be doing the trick, but it's insanely slow on my test PC, taking about 2-3 minutes per page!

    @PleegWat said:

    Also note in my experiments chrome outright refused to do anything CORS-like if nonstandard ports were involved.

    I do recall reading about that when I first discovered CORS a couple of weeks ago, but thanks for the warning. We will be using the standardish ports 80/443/8080/8443 (former pair for IIS, latter for Tomcat), with the caveat that if what I'm testing actually works, 8080 and 8443 will never be seen from the browser.


  • Discourse touched me in a no-no place

    Ugh. So my work PC is disgustingly slow, so I tried setting this up when I got home, where my machine's wildly faster. I set it all up and IIS won't load the tomcat connector dll, with nothing but a generic error (LoadLibraryEx failed). Curious, I wrote a simple program to load the DLL myself and call one of the exported functions in it, and it loads fine for me. :headdesk: :wtf: .



  • 32 vs 64 bits?


  • Discourse touched me in a no-no place

    Nope, I got the 64-bit dll, verified with dumpbin /headers, and it's 64-bit windows.

    The only thing left I can think of at the moment is to check the configuration information. The docs say you can either use a text file or a registry key to set some information; I used the registry at work, but the text file at home.


  • sockdevs

    Is IIS 64-bit? Probably, but just a sanity check ;)


  • Discourse touched me in a no-no place

    yes.


  • Discourse touched me in a no-no place

    Listen to this gibberish:

    "Note that in a 64 Bit environment - at least for IIS 7 - the used IIS Application Pool should have "Enable 32-bit Applications" set to "False". Otherwise the redirector will not be called and returns an http code 404. If you think, the 32bit version of isapi_redirect.dll would do the job instead, you will get an http code 500, because the library is not loadable into a 64 Bit IIS."

    First of all, that last sentence is just horrible. Second, if that's true, that a 32-bit dll won't work, then that's their fault, because the WHOLE POINT of "enable 32-bit applications" is to load 32-bit DLLs in 64-bit IIS. My company's apps require that functionality.



  • @FrostCat said:

    If you think, the 32bit version of isapi_redirect.dll would do the job instead, you will get an http code 500, because the library is not loadable into a 64 Bit IIS.

    How the hell do you even break that?


  • Discourse touched me in a no-no place

    @blakeyrat said:

    How the hell do you even break that?

    Who knows.

    The DLL fails to load, and completely kills IIS, and I've spent enough of my own time on it, so I disabled it. Tomorrow I guess I have to decide whether or not I dare ask for a new PC.



  • You shouldn't be doing work-work on your home computer anyway. If you work for a company that doesn't realize how much cost savings they'd get from a $800 computer purchase, you need to quit.


  • Discourse touched me in a no-no place

    I am well aware of that, and am getting to the point where I may do that. Mostly I like the place, though, and of course I'd have to track down a replacement job first.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    If you work for a company that doesn't realize how much cost savings they'd get from a $800 computer purchase

    Part of the problem is they have a tendency to be penny-wise, pound-foolish, and I'm as much afraid they'll give me another frigging Pentium instead of an i5. On of the senior devs told me he's using a 10yo XP machine. Good for you, dumb shit!


  • Grade A Premium Asshole

    @FrostCat said:

    On of the senior devs told me he's using a 10yo XP machine

    Any place that has not sent those off to be recycled is not a place you should be working. Time to polish the resume.


  • Discourse touched me in a no-no place

    @Polygeekery said:

    Any place that has not sent those off to be recycled is not a place you should be working.

    He doesn't seem to care! Probably because, as I said upthread, he doesn't actually do much on it--instead, he does his work on the dev server...which is just about as old, and stupidly slow. I at least have a machine that's only 4 years old. And it's upgraded to 8.1, because I'm not afraid of it like some people here.

    And if it doesn't die soon, it might just die "spontaneously".


  • Grade A Premium Asshole

    @FrostCat said:

    And if it doesn't die soon, it might just die "spontaneously".

    "So, since I am the senior dev I will get a new i7 machine and you can have my machine. It works great for me, plenty of life left in it."



  • "It already has all the dev tools and utilities you'll need on it. Visual Studio 2005, WinRAR, Microsoft Virtual PC 2007, Office 2003, etc."


  • Discourse touched me in a no-no place

    Ignoring the fact they'd have to ship the machine from New Jersey to Dallas to do that, I don't think he would care about getting an i7. I'd settle for an i5, which is probably good considering I doubt they'd spring for an i7. The only good point about that is my dev environment isn't C++ or Java and I honestly don't need quite that much power. It would be incredibly useful but I can manage without a powerhouse.


  • Discourse touched me in a no-no place

    Ha. We have the current-ish version of the environment we develop in, VS2K13 is free, and we're on Office 2010.

    I'm angling for a copy of Office 2K13 because my office uses COM interop and the increased security in 2013 breaks it. (Seriously, who thought "open a mail merge document in read-only mode by default" was a smart breaking change?)



  • @FrostCat said:

    Ah. Well, I can look into that. It would be lying, because that's not what the actual content type is, but maybe that's OK?

    I finally got Tomcat Connector to work. I somehow misread what one setting was supposed to be. Someone should tell these guys that if you have to have a setting be a specific value, there's not any real point in having it be something you could set and potentially get wrong. Just suck it up and accept you've got a magic constant. (For future reference: the extension_uri property is NOT the path to isapi_redirect.dll, it's the string "/jakarta/isapi_redirect.dll".)

    I figured it would be lying, but I'm betting their app won't know the difference given the state of their documentation. Also, depending on how you look at it, text/plain isn't necessarily a lie - the text just happens to be a properly formatted html document, and that one also doesn't trigger a preflight.



  • @FrostCat said:

    I tried to do that. The genius I mentioned above more or less flat-out refused to countenance the concept of enabling CORS.

    It looks like the tomcat connector will work for me--I am in the process of testing it right now. It's agonizingly slow on my PC: loading the first block of css/js/html at tomcat app session initiation is taking over a minute.

    Yeah, I saw that - I was going with the "put it in the config anyway and see if they notice you ignored them". The proxy tunnel should work fine.


  • Discourse touched me in a no-no place

    @rad131304 said:

    The proxy tunnel should work fine.

    Well, for some value of "fine". I was testing on an old 2.4GHz Pentium Dual-core with a 5400RPM laptop hard drive, and some pages actually took 3 minutes go make it through the tunnel. Today I'm duplicating the environment on an actual server.



  • @FrostCat said:

    Well, for some value of "fine". I was testing on an old 2.4GHz Pentium Dual-core with a 5400RPM laptop hard drive, and some pages actually took 3 minutes go make it through the tunnel. Today I'm duplicating the environment on an actual server.

    True. I figured a resources problem could be overcome and would be more easily accepted by your IT people.


  • Discourse touched me in a no-no place

    I am certainly going to mention that if it comes up. One problems is that we have two offices, and in mine we mostly work on a GUI app; the other, a web one. Those guys don't need powerful PCs as they don't develop on them, so they don't see the need. Which is crazy, because like I said, their servers are week too. Which is doubly crazy because the production ones for the product, which is a SaaS thing, are powerful, and they replace them very couple of years, so I don't know why they don't use the old ones to replace the dev environments.



  • It's amazing what a person can get used to.


  • Discourse touched me in a no-no place

    That's true.

    Over the last year, things have been changing and generally not for the better, which is why I'm beginning to consider leaving. It's still better than a number of other places I've worked.



  • This post is deleted!


  • How did I manage to discopost into a completely unrelated topic to the one I was reading?!


  • Discourse touched me in a no-no place

    Start a post, switch topics, hit the Reply button. The posting thing follows you even across tabs.


  • sockdevs

    It should ask you which thread you want to reply in though


  • Discourse touched me in a no-no place

    Just for the hell of it I tried setting up the env again on my PC this afternoon. Turns out it wasn't working due to permissions. I moved the connector DLL into c:\inetpub\wwwroot, reasoning the user that IIS runs as had access to that directory, and it worked.

    This was more or less a dry run so I can replicate this on an actual server at work tomorrow, something faster than my potato office PC.


  • Discourse touched me in a no-no place

    It should, yes.


  • Discourse touched me in a no-no place

    Bee Tee Dub, is anyone an IIS expert? I don't mean ASP, I mean IIS config. For this to work I believe I'm going to need two app pools, since the one that the connector will use cannot have "allow 32-bit DLLs", but the one our IIS application will use must have that set. My thought is to either give the site one app pool, and use the other one to our IIS application. Alternatively, it might be better to convert the connector Virtual Directory into an Application so it can have its own app pool instead of inheriting the site's pool. Is there any reason NOT to make a virtual directory into an application? We won't be using the application functionality (that is, the features that make an app differ from a virt dir).



  • @FrostCat said:

    I am certainly going to mention that if it comes up. One problems is that we have two offices, and in mine we mostly work on a GUI app; the other, a web one. Those guys don't need powerful PCs as they don't develop on them, so they don't see the need. Which is crazy, because like I said, their servers are week too. Which is doubly crazy because the production ones for the product, which is a SaaS thing, are powerful, and they replace them very couple of years, so I don't know why they don't use the old ones to replace the dev environments.

    IIRC, they have to actually get rid of the servers in order to write them off of their books to get the final bit of the tax break.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.