ORDS, SODA & JSON in the Database

Really need some help here. I can't be the only one with this issue.

if you call ords directly does it work? it looks like you have a reverse proxy setup, and if so, something is off between 9090 and 9075

Yes, if I use CURL it works just fine.

the DB machine, in standalone mode, is using port 9090, the web browser is running on a shared linux box and I have been assigned port 9075 for my web service running from IntelliJ.

I don't think it's a reverse proxy set up. I think I need to be able to tell the Jetty server running in the DB which URLs are OK for cross origin requests.

I found this info, but it requires APEX, we're not using apex, only ORDS. I'm guessing that there is some other way of setting this up?

This is proper if the authors of https://example.com do not trust the authors of https://thirdparty.com. However, if the authors do have reason to trust each other, then the Same Origin Policy is too restrictive. Fortunately, a protocol called Cross Origin Resource Sharing (CORS), provides a means for https://example.com to inform the web browser that it trusts https://thirdparty.com and thus to instruct the browser to permit gallery.html to make an XMLHttpRequest to https://example.com/ords/resteasy/gallery/images/.

E.8.6 Configuring a RESTful Service for Cross Origin Resource Sharing

To configure a RESTful service for Cross Origin Resource Sharing, follow these steps:

    Navigate to SQL Workshop and then RESTful Services.

    Click the module named gallery.example.

    For Origins Allowed, enter the origins that are permitted to access the RESTful service (origins are separated by a comma).

    Press Apply Changes

you can define Origins allowed on a RESTful Service module, but not on an individual REST enabled object like a table

That sounds like a bug or a design problem to me. How useful is enabling a table if you cannot call it from a different origin? 

Doesn't this make standalone problematic? I mean, you're making a REST call from a web server which is serving up the HTML/Angular and then to the DB, it's Cross Origin.

How do you see this working?

DEV is asking you record your http interaction so we can see exactly what's happening

instructions -

A HTTP Archive (.har file) is a recording of a web-browser's interactions with a web-site. You can use Chrome Dev-Tools to record a HAR of interactions of Chrome and a web-site, to illustrate performance or error issues encountered with the web-site.

Using Chrome Dev-Tools

Right click on the vertical ellipsis character on top right of the Chrome Menu Bar to bring up the menu. Click More Tools|Developer Tools to display Chrome Developer Tools

Click the Network tab to display the view of the HTTP requests Chrome is making.

• Click 'Preserve Log' to ensure the log endures past any page load transitions that may occur whilst reproducing the issue
• Navigate through the web-site until the issue you want to illustrate occurs.
• Once the issue has occured, right click on the pane at the bottom of the Network tab, showing the requests that have been made
• Choose Save as HAR with content
• Save the file as prompted.
  
  

Then attach the file here

Hope this helps. I had to change the file type because this site wouldn't allow uploading of a har file.

Ok, so interestingly enough, if I create a "post" or put module. I do NOT get the CORS error. It's only on the table enabled POST (and PUT) that there is a problem.

I don't even have to add to the "Origins Allowed" tab for the module.

Not sure why ORDS is executing the table enabled code in a different manner than the modules, but you REALLY need to be able to handle this I think.

>>Not sure why ORDS is executing the table enabled code in a different manner than the modules, but you REALLY need to be able to handle this I think.

this is a community forum, if you want support, you should be opening service requests with my oracle support

I hang out here to help people as I can...

And ORDS isn't executing table enabled code in a different manner...what you're seeing is different behavior between the two, but we don't have any idea how you've setup your system.

Also this - as you can see ORDS is working. There's something going on with your setup that hopefully your log file will show what's going on. I'm not even sure what the below even means.

Yes, if I use CURL it works just fine.

the DB machine, in standalone mode, is using port 9090, the web browser is running on a shared linux box and I have been assigned port 9075 for my web service running from IntelliJ.

I have opened a service request. Just hoping that there was an answer to this.

Jeff, I do *REALLY* appreciate your help. It is great.

It is clearly doing different things when calling the table API than when you call a module. Look at the network traffic and how it's handled. What's going on on the REST side is different, not the call itself.

This (a table enabled call) will fail:

this.http.put <Hero> ("http://gendbracdev:9090/ords/trex/heroes", hero).subscribe()

While this (a module) succeeds

this.http.put <Hero>("http://gendbracdev:9090/ords/trex/hw/hw", hero ).subscribe();

Here is the option that succeeds

I'm not even sure what the below even means.

You asked if I called ORDS directly does it work. The only way I know to call it directly is from CURL or Postman and, yes, it works with either, but it's not using a browser so, of course it works.

ORDS is running in standalone mode in the database which gives it a different origin than the web server. I would think that ANY time you're using standalone mode and using a web server to do say, Angular, you're going to have this problem with the Table enabled ORDS.

That was it!

You are the Best! Thanks for your help!