Hello John,

the problem is that the preflight request comes without any
authorization (because it is asking the server what is allowed) and
therefore it always returns 403.

in client.py line 652 (with the patch applied) it reads:

if not self.db.security.hasPermission('Rest Access', self.userid):
     self.response_code = 403

user is "anonymous" here as we have no auth data in the preflight request.

thats what the patch in client.py (below "# handle preflight...")
addresses.

at this point the patch  allow everything that is supported down the way
(hopefully), assuming that at deeper levels somewhere things get
forbidden based on permissions and other rules.

the

	@Routing.route("/data/<:class_name>", 'OPTIONS')

section never gets hit at this point, because it only would if someone
has "Rest Access" permission. which anonymous dont has.

but maybe it should for that reason ? maybe that would be too open ?
maybe anonymous should just have enough permission to reach the code
above to send correct cors headers? - which probably would be better
than sending one answer for all ? ... but i am not that deep in the
permission thing if this is possible :(

acc. to max-age i found out that Access-Control-Max-Age indeed is a time
saver when you access same endpoint within the time range as the OPTIONS
request then gets not sent by the browser. maybe this should be
configurable for the user ?

> My initial thought is that iframe would be used for this which IIRC
> doesn't use CORS. It has other restrictions in CSP etc. However IIRC
> download/upload of files runs through the web endpoint so we might
> need something there as well. What use cases do you have in mind?
> Would Roundup supply HTML partials/fragments to be composed on the
> client?

i also think that iframes dont use cors, but iframes are ugly anyway ;)

i dont have anything in mind, but i can imagine someone building a
frontend requesting html fragments (maybe running through tal for
i18n ;)) or something else ...

i am rather thinking about where to put the code to address all possible
use cases at once ...

when you say xmlrpc is working over post - hmmm, i dont think it would
be needed because most likely there will be no browser talking to it ...
but can be, if someone is wierd enough to build a webpage using xmlrpc
instead of rest ;)

in the end it's all just plain http requests ... so i would vote to have
the CORS thing for all http requests.

regards,
marcus.