I have deployed a custom UI5 app ( using external REST ful services--> service hosted in another Java stack system) in the front end server.
I used Ajax to call the service directly with the URL as shown below.
This app has run successfully when i use "proxy" in local host(eclipse).
-->Ajax Call code Snippet
So i replaced proxy with target url while deploying in front end. (http ://xxx.xxx:port)
When running from front end server i got cross origin error as shown below.
Error1:<http://xxx:port/xxx/ngservices/rest/query/ZQUE_WEBSERV_APPHISTORY/executeGet. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://xxx:port' is therefore not allowed access. The response had HTTP status code 401>
After enabling CORS plugin in chrome i got unauthorised error as shown below.
Error2:<http://xxx:port/xxx/ngservices/rest/query/ZQUE_WEBSERV_APPHISTORY/executeGet. Response for preflight has invalid HTTP status code 401>
I got the above errors initally while running from localhost.After that i used proxy and it got solved.
I just deployed the app in frontend server and ran it directly. I haven't done any other configurations.
Do i need to do any extra configurations for consuming these external services or kindly suggest any other suggestions.
Important info:
*Able to call external service from localhost(eclipse--> used proxy here) but not able to call service from frontend server.
*Front end architecture: Central hub deployement and connected to SRM,HR and CRM backends currently.
Regards
Phani Poorna
Both of these errors can be solved by creating and configuring a destination on your platform.
A destination is essentially a proxy: when you create it, you specify the backend URL, the authentication mechanism (Principal propagation/basic authentication etc). From your client, you just need to then connect to your destination to query the backend.
What do you mean by Fiori front end server? Are you referring to the Portal service hosted on HANA Cloud Platform?
If so, then you can create a destination by going to Connectivity - Destinations from your HCP account. From your Fiori application, you then need to connect your destination using the following URL pattern:
/destinations/<destination name>/<whatever you want to add to the URL the destination points to>
If you are using a different PaaS, I'm sure it will have some similar way of creating a proxy between your client and your backend. (Edit: I just saw you're using the Central hub deployment - I am not familiar with this system but it must have a very similar way of creating destinations).
Hope this helps, let me know if you have any questions.
Related
New to Container Apps.
I'm trying to understand basic connectivity between services in Container Apps.
Lets say I have a web front in .Net Core and an Web API backend (.Net Core).
Without containerization, I could put the base address of my web api in my app settings of the front end to connect to the api, lets say localhost:5000 etc. Using an httpClient to do the call.
If I containerize the front end and api and deploy it to ACA, what would that look like? I think its would be like:
Ingress external for front end
Ingress internal for api
Port 80 for both front end and web api????
Or do I need to setup a base address of some sort to call the web api? Or an environment variable?
I put both ports to 80 but they cannot seem to connect.
Thanks!
In your "Without containerization" example, if your web ui is running on localhost:8080 for example, and your API is running on localhost:5000 then you'll need to enable CORS on the api. In That example, both your web ui and your api are "external". Anything you need to call from a browser is 'external'.
Internal only are for server to server communication, or microservices communicating with each other.
In your example, you'd deploy both as external apps, this will give you 2 domains https://webui.env.region.azurecontainerapps.io and https://api.env.region.azurecontainerapps.io then you will configure a CORS policy on the api app.
see this for more details
I developped an application NUXTJS with a backend in Symfony. I deploy an API REST that allows me to talk beetween front and back. Everything work in local.
I want to deploy this on my host.
So I created two subdomains : one for my front and one for my backend.
So when I try to access to my application, I try to connect but I have these two errors CORS :
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://mysubdomain.domain.fr/api/login_check. (Reason: CORS header 'Access-Control-Allow-Origin' missing).
And
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://mysubdomain.domain.fr/api/login_check. (Reason: CORS request did not succeed).
How can I fix this ?
Thanks a lot
You need to enable CORS by specifying the nextjs domain, not the api domain. If you want to be sure you can also allow all domain by using a *. But this reduces security a bit.
If you really want to be secure, you could add a proxy to your nextjs server, which proxies to your Symfony application. For example, in your NextJS application, proxy /api to the Symfony application hostname.
This way you don't need to enable CORS at all.
If you use Api Platform you may need to configure the CORS_ALLOW_ORIGIN variable in your .env file 😁
I am developing a web service using REST API. This REST API is running on port 6443 for HTTPS. Client is going to be a Single page application running on port 443 for HTTPS on same machine. The problem I am facing is:
While I hit the url say: https://mymachine.com/new_ui I get certificate exception for an invalid certificate because I use a self signed one, so mymachine.com:443 gets added to server exception. But still requests doen't go to REST API as they are running on https://mymachine.com:6443/restservice. If I manually add mymachine.com:6443 to server exception on firefox it works but it will not be the case in production for customers.
Some options that I thought are:
1. Give another pop up and ask to add REST server on port 6443 exception too.But this doesn't look proper as why an end user should accept the cerf for same domain twice. Also REST api server port can change.
Can we programmatically add exception for domain and both the ports in one shot? Ofcourse with the consent of the user. 3. Use a reverse proxy. But then its going to have memory footprint on our system. Also it will be time consuming.
Please suggest some options. How do I deal with it. Thank you
I am running Cisco UCCX 11.0 which is a Contact Center server that is based on a Java scripting engine. Scripts are build using the 'Script Editor' software where you drag elements (Java Beans) to define the script logic. One of the steps in the script is to perform a REST Call. Unfortunately this step does not support adding Custom Headers such as Authorization headers and thus is limited to Basic Authentication only.
I would like the script to make a REST Call to an external API that uses a static Bearer Token. Am I correct in saying I could use Kong Gateway for this? Here is my idea of the flow:
UCCX Makes REST Call to Kong with Basic Authentication ---> Kong Gateway recieves the request ---> Kong Gateway makes it's request to External API with static Bearer Token ---> External API responds back to Kong ---> Kong forwards the Response back to UCCX
Is this type of flow possible/easy to deploy?
This can easily be managed by assigning the Request Transformer plugin to the Kong API exposing the upstream service.
Example:
Let's assume you have an API endpoint on Kong called /myapi that is forwarding to your upstream service.
You then assign the Request Transformer plugin to the /myapi API.
For your case, you will most likely want to be using the config.add.headers option when configuring the Request Transformer plugin to add the required header authentication which will be added to all upstream requests.
Relevant Gitter Conversation:
https://gitter.im/Mashape/kong?at=587c3a9c074f7be763d686db
I have implemented the supporting of SAML SSO to have my application act as the Service Provider using Spring Security SAML Extension. I was able to integrate my SP with different IDPs. So for example I have HostA,HostB, and HostC, all these have different instances of my application. I had an SP metadata file specified for each host and set the AssertionConsumerServiceURL with the URL of that host( EX:https:HostA.com/myapp/saml/sso ). I added each metadata file to the IDP and tested all of them and it is working fine.
However, my project also supports High Availability by having an IBM HTTP Server configured for load balancing. So in this case the HTTP Server will configure the hosts(A,B,C) to be the hosts used for load balancing, the user will access the my application using the URL of the HTTP server: https:httpserver.com/myapp/
If I defined one SP metadata file and had the URL of the HTTP Server specified in the AssertionConsumerServiceURL( https://httpserver.com/saml/sso ) and changed my implementation to accept assertions targeted to my HTTP Server, what will be the outcome of this scenario:
User accesses the HTTPServer which dispatched the user to HostA(behind the scenes)
My SP application in HostA sends a request to the IDP for authentication.
The IDP sends back the response to my httpserver as: https://httpserver.com/saml/sso .
Will the HTTP Server redirect to HostA, to have it like this: https://HostA.com/saml/sso
Thanks.
When deploying same instance of application in a clustered mode behind a load balancer you need to instruct the back-end applications about the public URL on the HTTP server (https://httpserver.com/myapp/) which they are deployed behind. You can do this using the SAMLContextProviderLB (see more in the manual). But you seem to have already successfully performed this step.
Once your HTTP Server receives a request, it will forward it to one of your hosts to URL e.g. https://HostA.com/saml/sso and usually will also provide the original URL as an HTTP header. The SAMLContextProviderLB will make the SP application think that the real URL was https://httpserver.com/saml/sso which will make it pass all the SAML security checks related to destination URL.
As the back-end applications store state in their HttpSessions make sure to do one of the following:
enable sticky session on the HTTP server (so that related requests are always directed to the same server
make sure to replicate HTTP session across your cluster
disable checking of response ID by including bean EmptyStorageFactory in your Spring configuration (this option also makes Single Logout unavailable)