CORS and Access-Control-Allow-Origin

[Richard Herbert]

This subject is very much on the edge of my knowledge and understanding right now so please excuse and correct any errors in comprehension.

I'm experimenting with Taffy to support a cross domain request and I'm hitting CORS, which is fine. 

I've found the "allowCrossDomain" framework setting and it works as advertised and has allowed me to progress.

What I'm looking for is a way to lock down the handling of requests, in line with my understanding of CORS, and only provide a "Access-Control-Allow-Origin" for an authorised domain such as "http://www.example.com" rather than the wildcard "*".

As I see it there are two choices:

* I turn off "allowCrossDomain" and provide my own header values with ".withHeaders()"

* Find a way to extend Taffy to support a, per-request, "Access-Control-Allow-Origin" value

Thoughts?

--

Richard

[Adam Tuttle]

It's funny how things come in waves. Another developer showed me that he needed this same thing just a couple of days ago.

I think he was going to put together a pull request, but if he doesn't get to it today I might just have to knock it out. Basically the idea will be that instead of setting allowCrossDomain to true, you will set it to an array of allowed domain names, and Taffy will take care of the rest.

Adam

--
You received this message because you are subscribed to the Google Groups "Taffy Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to taffy-users...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Richard Herbert]

It is indeed!

I was thinking of something more flexible whereby the resource could decide the domain to return in the header. The services I'm working on may all not be available to all the domains in a centralised array.

[Adam Tuttle]

Interesting...

Well, you could always disable CORS in the framework config, and sort of re-implement it in your resources, and pass the resulting headers into your response headers in .withHeaders()... If you go that route, I'd create an intermediate class like myBaseResource which extends taffy.core.resource and includes function(s) with your reimplementation details for generating appropriate headers, and each of your resources would extend myBaseResource, and use it as needed.

I suppose we could put something similar into taffy.core.baseResource, too.

I've just learned that I'm not going to have ANY free time today, though, so you're on your own for the time being. :)

Good luck!

Adam

[Richard Herbert]

Yes, that was one of my possible solution routes that I mentioned but I just wanted to see if I'd missed anything or that anything else was in the works.

I'll take your intermediate class idea and see if I can get something working that meets my needs.

Thanks for your time.

--

Richard

[Adam Tuttle]

Hi Richard,

Today in IRC Dan Skaggs poked me about this. The Pull Request I had referenced in this email thread never happened, so I've gone ahead and coded it myself. It is as of yet undocumented, and only available in the Bleeding Edge Release (download master from github), but it's there! It'll be included in 3.1 whenever that happens.

Thanks,

Adam

[Richard Herbert]

Thanks for that Adam.

I'll take a look and consider replacing my intermediate class solution.

--

Richard