RE: CORS, Azure, Chrome desktop and mobile

[Adrian Halid]

http://jeffmcmahan.info/blog/firewall-causes-cors-to-fail/

 

The comments in this post suggest using TSL/SSL. The firewall can’t mess with 
your headers.

 

Regards

 

Adrian Halid 

 

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of David Burstin
Sent: Tuesday, 13 October 2015 2:08 PM
To: Thomas Koster 
Cc: ozDotNet 
Subject: Re: CORS, Azure, Chrome desktop and mobile

 

Firstly, thanks again to everyone who has taken the time to look at this.

 

Yes, it turns out that it is a firewall issue. :(

 

So, given that having a web page talk to a web service at a different origin is 
not a crazy or unusual situation, how do you guys deal with this? How do you 
make the web page work, given that you can't go to everyone who looks at your 
site and ask them to change their firewall rules, no matter how dumb they are 
(the firewall rules and the people you are talking to)?

 

Or is it just not possible?

 

Cheers

Dave

 

On 13 October 2015 at 16:53, Thomas Koster  > wrote:

On 13 October 2015 at 15:39, David Burstin  > wrote:
> My response headers don't have "Access-Control-Allow-Origin". Any ideas
> why? (I am about to hit google)

On 13 October 2015 at 16:11, Thomas Koster  > wrote:
> Are you using a proxy, firewall or browser plugin that is removing them?
> If you suspect this, try HTTPS (although a browser plugin can still bite
> you).

On 13 October 2015 at 16:15, David Burstin  > wrote:
> Thanks Thomas. Definitely not a plugin, possibly a proxy or firewall issue.
> I will talk to the guys here who know more about this than me.

At first, looking at your screenshot, I didn't think that a proxy or
firewall was removing headers because outgoing headers look fine and
rubbish headers like "X-Powered-By" did make it through. (Why include
"X-Powered-By" on a whitelist but not CORS headers?!). But then I
noticed that "X-AspNet-Version" is also missing from your
screenshot...

--
Thomas Koster

 

RE: CORS, Azure, Chrome desktop and mobile

[David Burstin]

Thanks Adrian. I saw that and will try it tonight when I get home (I need
to make the service call ssl too). Azurewebsites.net has an ssl
certificate, so it should all work once it is end-to-end ssl.
On 13 Oct 2015 6:42 pm, "Adrian Halid"  wrote:

> http://jeffmcmahan.info/blog/firewall-causes-cors-to-fail/
>
>
>
> The comments in this post suggest using TSL/SSL. The firewall can’t mess
> with your headers.
>
>
>
> *Regards*
>
>
>
> *Adrian Halid*
>
>
>
> *From:* ozdotnet-boun...@ozdotnet.com [mailto:
> ozdotnet-boun...@ozdotnet.com] *On Behalf Of *David Burstin
> *Sent:* Tuesday, 13 October 2015 2:08 PM
> *To:* Thomas Koster 
> *Cc:* ozDotNet 
> *Subject:* Re: CORS, Azure, Chrome desktop and mobile
>
>
>
> Firstly, thanks again to everyone who has taken the time to look at this.
>
>
>
> Yes, it turns out that it is a firewall issue. :(
>
>
>
> So, given that having a web page talk to a web service at a different
> origin is not a crazy or unusual situation, how do you guys deal with this?
> How do you make the web page work, given that you can't go to everyone who
> looks at your site and ask them to change their firewall rules, no matter
> how dumb they are (the firewall rules and the people you are talking to)?
>
>
>
> Or is it just not possible?
>
>
>
> Cheers
>
> Dave
>
>
>
> On 13 October 2015 at 16:53, Thomas Koster  wrote:
>
> On 13 October 2015 at 15:39, David Burstin 
> wrote:
> > My response headers don't have "Access-Control-Allow-Origin". Any ideas
> > why? (I am about to hit google)
>
> On 13 October 2015 at 16:11, Thomas Koster  wrote:
> > Are you using a proxy, firewall or browser plugin that is removing them?
> > If you suspect this, try HTTPS (although a browser plugin can still bite
> > you).
>
> On 13 October 2015 at 16:15, David Burstin 
> wrote:
> > Thanks Thomas. Definitely not a plugin, possibly a proxy or firewall
> issue.
> > I will talk to the guys here who know more about this than me.
>
> At first, looking at your screenshot, I didn't think that a proxy or
> firewall was removing headers because outgoing headers look fine and
> rubbish headers like "X-Powered-By" did make it through. (Why include
> "X-Powered-By" on a whitelist but not CORS headers?!). But then I
> noticed that "X-AspNet-Version" is also missing from your
> screenshot...
>
> --
> Thomas Koster
>
>
>

Re: vb.net

[mike smith]

C++ is the Only Way.  And get off my v-lawn!

:)



On Tue, Oct 13, 2015 at 2:19 PM, David Burstin 
wrote:

> I think the real message here is - forget the language, just don't work
> for Nelson's senior. Stubborn a**h are not confined to any particular
> language. :)
>
> On 13 October 2015 at 14:14, Nelson  wrote:
>
>> My concern here (regarding the job offer) is not about the language use.
>>
>> i cannot stress enough how a pain in the a** it can be when working with
>> seniors who are reluctant to change and adopt newer better technology.
>>
>> And as a Junior in the team you are basically screwed, especially you
>> started your training with all the modern tech and tools.
>>
>>
>>
>> I had a hard time convincing my senior to switch to ASP.NET MVC from
>> WebForms.
>>
>> although that turn out may not be the best idea - he still code like
>> WebForms way in MVC
>>
>> anyway he still thinks WebForms is superior and can do stuff MVC cant do
>> till this date unfortunately
>>
>>
>>
>> you can also imagine how your ideas got banned just because you are the
>> junior and he play the experience game with you.
>>
>> even though that experience translate to sticking to 10-20 years old
>> libraries when there are modern, much more popular alternatives
>>
>> (the best example i think of right now is that he is still using his copy
>> of a 1997 alpha version of date.js library - probably thats the time he
>> started learning js?)
>>
>>
>>
>> I'm not saying VB.NET people are all stubborn and old. but the
>> probability of having to work with a**h*** is just much higher than i like.
>>
>> After all, it won't be a cultural fit for me personally as i'm a
>> state-of-the-art person and would love to work with new technology
>>
>>
>> On 13 October 2015 at 13:53, Bill McCarthy <
>> bill.mccarthy.li...@live.com.au> wrote:
>>
>>>
>>>
>>> Although there’s lots of c ‘style’ languages, the devil is always in the
>>> details/differences. I find it hard to switch between c# and js and not
>>> forget/mess up. With vb.net and js not so much a problem.
>>>
>>>
>>>
>>> The same use to be said for vb and vbscript in days of asp
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From: *David Burstin
>>> *Sent: *Tuesday, 13 October 2015 1:41 PM
>>> *To: *ozDotNet
>>> *Subject: *Re: vb.net
>>>
>>>
>>>
>>>
>>>
>>> I started my .net journey with vb.net, but these days I code C# unless
>>> I have to use vb for working with a legacy system.
>>>
>>>
>>>
>>> I agree with Bill - there really isn't much difference between using the
>>> languages in .net. In fact, knowing my way around the .net framework (from
>>> having used it with vb) made the transition to c# much easier.
>>>
>>>
>>>
>>> BUT, outside the .net world, I have found my knowledge of C# has helped
>>> me in reading (and learning) other languages - eg java, js, ruby. These all
>>> have a syntax which is far more like c# than vb.
>>>
>>>
>>>
>>> So, if you can only use one language, for me it would be C# - but there
>>> is no reason at all that you should be confined to one language. If you are
>>> interested in the job, than go for it. Whatever happens, you will learn.
>>> Any job provides an opportunity to practice our craft and become better
>>> programmers. Plus, you can do projects after hours in whatever language you
>>> want :)
>>>
>>>
>>>
>>> Cheers
>>>
>>> Dave
>>>
>>>
>>>
>>> On 13 October 2015 at 13:33, Bill McCarthy <
>>> bill.mccarthy.li...@live.com.au> wrote:
>>>
>>>
>>>
>>>
>>>
>>> This usually a great rant starter for a Friday conversation.
>>> Realistically though Vb.net is much a muchness with c# on .net. Definitely
>>> the best language if doing integrated xml. With late binding stuff it has
>>> some advantages with better conversions, but also disadvantages such as
>>> wider scope.
>>>
>>>
>>>
>>> Realistically the biggest disadvantage of vb.net is if you want to
>>> integrate some large source code from open licence stuff... usually more is
>>> available in c#.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From: *Tom P
>>> *Sent: *Tuesday, 13 October 2015 12:48 PM
>>> *To: *ozDotNet
>>> *Subject: *vb.net
>>>
>>>
>>>
>>>
>>>
>>> Guys I've been offered a junior dev job but they insist on vb.net only.
>>> Does anyone know what is happening with vb.net going forward? I would
>>> hate to get stuck into the vb.net world and have it killed off within a
>>> few years.
>>>
>>>
>>> Thanks
>>>
>>> Tom
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>


-- 
Meski

 http://courteous.ly/aAOZcv

"Going to Starbucks for coffee is like going to prison for sex. Sure,
you'll get it, but it's going to be rough" - Adam Hills

Re: CORS, Azure, Chrome desktop and mobile

[David Burstin]

Firstly, thanks again to everyone who has taken the time to look at this.

Yes, it turns out that it is a firewall issue. :(

So, given that having a web page talk to a web service at a different
origin is not a crazy or unusual situation, how do you guys deal with this?
How do you make the web page work, given that you can't go to everyone who
looks at your site and ask them to change their firewall rules, no matter
how dumb they are (the firewall rules and the people you are talking to)?

Or is it just not possible?

Cheers
Dave

On 13 October 2015 at 16:53, Thomas Koster  wrote:

> On 13 October 2015 at 15:39, David Burstin 
> wrote:
> > My response headers don't have "Access-Control-Allow-Origin". Any ideas
> > why? (I am about to hit google)
>
> On 13 October 2015 at 16:11, Thomas Koster  wrote:
> > Are you using a proxy, firewall or browser plugin that is removing them?
> > If you suspect this, try HTTPS (although a browser plugin can still bite
> > you).
>
> On 13 October 2015 at 16:15, David Burstin 
> wrote:
> > Thanks Thomas. Definitely not a plugin, possibly a proxy or firewall
> issue.
> > I will talk to the guys here who know more about this than me.
>
> At first, looking at your screenshot, I didn't think that a proxy or
> firewall was removing headers because outgoing headers look fine and
> rubbish headers like "X-Powered-By" did make it through. (Why include
> "X-Powered-By" on a whitelist but not CORS headers?!). But then I
> noticed that "X-AspNet-Version" is also missing from your
> screenshot...
>
> --
> Thomas Koster
>

Re: CORS, Azure, Chrome desktop and mobile

[Nelson]

as you see from the responses for the thread, all of us are working just
fine.


if its the network admin's decision to intentionally block web requests

then its their issue, not developers'.


Your app is fine. time to throw the ball - there is nothing you can do as a
developer around specific firewall rules of different networks


On 13 October 2015 at 17:07, David Burstin  wrote:

> Firstly, thanks again to everyone who has taken the time to look at this.
>
> Yes, it turns out that it is a firewall issue. :(
>
> So, given that having a web page talk to a web service at a different
> origin is not a crazy or unusual situation, how do you guys deal with this?
> How do you make the web page work, given that you can't go to everyone who
> looks at your site and ask them to change their firewall rules, no matter
> how dumb they are (the firewall rules and the people you are talking to)?
>
> Or is it just not possible?
>
> Cheers
> Dave
>
> On 13 October 2015 at 16:53, Thomas Koster  wrote:
>
>> On 13 October 2015 at 15:39, David Burstin 
>> wrote:
>> > My response headers don't have "Access-Control-Allow-Origin". Any ideas
>> > why? (I am about to hit google)
>>
>> On 13 October 2015 at 16:11, Thomas Koster  wrote:
>> > Are you using a proxy, firewall or browser plugin that is removing them?
>> > If you suspect this, try HTTPS (although a browser plugin can still bite
>> > you).
>>
>> On 13 October 2015 at 16:15, David Burstin 
>> wrote:
>> > Thanks Thomas. Definitely not a plugin, possibly a proxy or firewall
>> issue.
>> > I will talk to the guys here who know more about this than me.
>>
>> At first, looking at your screenshot, I didn't think that a proxy or
>> firewall was removing headers because outgoing headers look fine and
>> rubbish headers like "X-Powered-By" did make it through. (Why include
>> "X-Powered-By" on a whitelist but not CORS headers?!). But then I
>> noticed that "X-AspNet-Version" is also missing from your
>> screenshot...
>>
>> --
>> Thomas Koster
>>
>
>