flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Mclean <jus...@classsoftware.com>
Subject Re: git commit: [flex-asjs] [refs/heads/develop] - CORS security. Allow auth credentials to be passed when using cross site calls. This is required as well as setting the Access-Control-Allow-Origin header on the server.
Date Mon, 10 Apr 2017 08:32:22 GMT

>  And the net result should be that code you didn't in your app, isn't in your app.

As Greg pointed out the compiler can removed unused JS code i.e. methods that are not called.
See for instance [1] for details. So in this case if you don’t use it will not end up in
the AS code (as it’s JS only) and will not end up in production JS code.

> So when you break stuff out into a bead, we want the net code size and performance for
> someone not using the bead to be the same or better.

In this case it is the same, if it was moved to a bead it would be worse for people who needed
it. Only by tiny amounts but that’s the point you’re trying to make i.e. slow dead by
a 1000 tiny additions, and as you say lots of people will need CORS support.

> It is certainly worth revisiting the code we've written to see if other
> stuff can be pulled out into beads, so thanks for reviewing HTTPService.
> It is one of the early classes and probably needs a review.  Given the
> above, my responses are inline below.

We should provide clear documentation on this, currently there is none? Having our own code
not following the same philosophy is a barrier for people contributing. In most other Apache
projects if someone submits a patch that may not be “perfect” other committers will help
to improve it. Pull request welcome and all that.

> Possibly.  As long as the implementation for folks not using headers would
> be smaller/faster.

That is likely to be the case, but it will be slower for people who do use headers. How do
we determine what is the most common use case? Isn’t that going to vary by use / customer
so we going to end penalising someone no matter which way we go.

> Possibly, but I claim that nobody should go into production without
> supporting timeouts, so I would leave that baked in.

So why does this not apply to the method I added? Every single project I’ve worked on has
made cross domain calls. It's very uncommon for web applications to have their database, rest
services, API calls on the same domain and quite common to call 3rd party services.

And I’m sure no one would go into production without supporting security of some form. I’m
concerned her that we are making security an optional feature here and not having it supported
by default.

> Again, if you can find a way to refactor that out without making the
> HTTPService bigger/slower, then great.

Anytime you place something in a bead it is going to be bigger and slower for the people that
need that functionality. It will be faster/smaller for the others who don't. So again how
do we determine what is the most common use case? Do more people use AIR status code than
don’t use them? I would guess not in this case and it should be a bead but it’s just a

> Like Timeout, I claim that nobody should go into production without
> handling errors.  So probably, the JS errors need to be handled right in
> HTTPService or HTTPServiceBase. 

So you're saying that HTTPService is where JS security errors should be handled and not in
a bead?


1. https://developers.google.com/closure/compiler/docs/api-tutorial3
View raw message