Authorization forbidden when using Orbeon eXist DB REST API - api

I'm new to Orbeon 4.1 and I'm trying to query the Orbeon eXist DB from an external application.
When I query for a form instance I keep getting a "not authorized" error. For example:
GET request:
http://localhost:8080/orbeon/exist/rest/db/orbeon/fr/test-app/test-form/data/9b9b4f73af642fe042ec4cf7b4f03c64fa15fbd4/data.xml
Response:
HTTP Error 403 (Forbidden): The server refused to fulfill the request.
Any ideas what I might be doing wrong?
EDIT:
I ended up installing eXist-db as a stand-alone webapp. Now I can query the eXist-db REST API directly and everything seems to be working fine.

This is because since version 4, services are protected by default, as you most likely don't want your users to be able to access eXist or the persistence services. You can open those services again, but instead, it is better to setup an authorization service, and have whoever calls the services authenticate itself.

Related

Cannot get nopCommerce to work on godaddy hosting version 4.2

HTTP Error 502.3 - Bad Gateway
There was a connection error while trying to route the request.
Most likely causes:
•The CGI application did not return a valid set of HTTP errors.
•A server acting as a proxy or gateway was unable to process the request due to an error in a parent gateway.
Things you can try:
•Use DebugDiag to troubleshoot the CGI application.
•Determine if a proxy or gateway is responsible for this error.
Detailed Error Information:
Module
AspNetCoreModule
Notification
ExecuteRequestHandler
Handler
aspNetCore
Error Code
0x8007000d
Requested URL
http://localhost:15536/
Physical Path
C:\Users\HenryP\Desktop\NopCommerce_4.2.0\src\Presentation\Nop.Web
Logon Method
Anonymous
Login User
Anonymous
More Information:
This error occurs when a CGI application does not return a valid set of HTTP headers, or when a proxy or gateway was unable to send the request to a parent gateway. You may need to get a network trace or contact the proxy server administrator if it is not a CGI problem.
View more information »
It seems this is not CGI issue. Newest nopCommerce version run on .net core version and require Full Trust. And my experience used Godaddy in the past that they didn't support Full Trust, so you can't install nopCommerce on their platform. You better contact their support team or you can ask this issue on nopCommerce forum. But, it seeems that nopCommerce can't run well on Godaddy platform. If you use nopCommerce, I recommend you can check Asphostportal.
According to your description, this is a generic error for when IIS can't find the specified .NET Core components ,and doesn't know where to forward requests.So i suggest you to check once you select asp.net or asp.net core while creating your site

PowerApps to call Azure API App

I am new to PowerApps development. I am trying to connect PowerApps to my custom APIs (Azure app api) and getting results of "resource not found". I can call the api from browsers, postman no problem. The .json file I use for PowerApps is the same as the one I use for editor.swagger.io (for testing). I checked the log file of the application on azure, all of the requests from browsers logged but not the ones from PowerApps. My question is, how PowerApps calls APIs and what is the right format of the .json file used for PowerApps app?
Thank you.
I would recommend trying again, we had a small issue on our backend that was causing some 404's at times. A fix for it has been deployed so you might see it work.
PowerApps uses Swagger to determine the shape of the REST api to be able to project those APIs into "formulas" that can be used easily in the client.
Also, for development/troubleshooting purposes I highly recommend using Fiddler to see exactly the REST call that PowerApps is doing and making sure the URL and parameters are correct. If not then look into your swagger definition and make sure there are no issues with the paths provided there.
You might also check that your Azure App API has either:
The PowerApps IP Addresses Whitelisted OR
If available, the "Allow Access to Azure Services" option toggled
When building Azure SQL backends for PowerApps, one of these paths must be followed.

Apigee - Issue while configuring an API Proxy

I'm looking for a way to expose my customer's WCF Services as REST Services (and create all the security stack to support claims / oauth authentication and authorization)
I'm working on 2 different approach to do so:
Create a new REST Service which will act as a proxy to
expose my WCF Service as REST Services (11 services / 130 web methods to
migrate...) and secure it using an IP STS / RS STS
Use a existing product like Apigee which will do all those job for me and even more feature than initially planned.
I'm trying to play with Apigee first, but I'm facing an issue while creating the API Proxy.
I've deployed a simple WCF Service (with only 2 methods) on a Windows Azure VM exposed in basicHttp (which works as expected - means I test it in a Console app successfully, even when the client app is located outside my Azure's VM -).
Problem comes when I follow the Apigee workflow to expose it as a REST Service. I try to fetch service's wsdl on Apigee portal and got following error:
Error: Cannot invoke method getOperation() on null object
Does someone know where the issue come from ? I don't have much information from Apigee portal.
I already validate my wsdl through http://www.wsdl-analyzer.com/ but everything looks fine...
Meantime, Amazone webservice works fine on Apigee and generate the REST Service so problem seems to come from my service's WSDL
This bug has been fixed and will be included in the next release (R24.4). If you still have any problems with the new release, please let us know.
I recently got a similar error in the most recent version of Apigee (Version 141029).
The error: "Fetch WSDL Error: Cannot invoke method startsWith() on null object".
The fix was to rename my local file from "somename.xml" to "somename.wsdl".

Returning a 401 Unauthorized from WCF Web API in an MVC 3 App

I'm using the WCF Web API (the latest version, which I think is 0.5, obtained from the VS2010 Ultimate integrated package dependency GUI).
I've got a simple API class exposed and in each method I'm making a call that performs authorization against the user. When the user is unauthorized, I throw an HttpResponseException with the 401/unauthorized code.
This works, and you can see that at some point in the Http Handler chain, the 401 was trapped. The problem is that the site in which the API resides contains ASP.NET Forms authentication... and so when it sees the 401, it tries to forward my client request to the logon page.
How do I disable this behavior for a particular sub-directory within my site? I've tried setting a location of "api" always allowing users... but I still throw a 401 which still causes ASP.NET to try and redirect me to the logon page.
I'm sure I'm just missing a simple configuration setting that tells forms auth to ignore requests for the /api/* directories, but I can't find any information on it.
I have described the problem and it's solution here (with Preview4): Basic Authentication with WCF Web API hosted in IIS / Getting a 404 - Disable Forms Authentication Redirection

Why do I get a 403 error when calling a WCF Webservice?

I'm really posting this question so that others searching for the answer can find it.
Scenario:
WCF Service: Has worked fine at some point but currently is returning 403 errors. The web.config looks fine as far as I can tell. This machine has set the web.config to disable transport and message security and is using BasicHTTPBinding.
When I call it with my client generated from the Service Reference in Visual Studio, I get a 403 error. The error indicates there is some problem with the authentication, but as far as I can tell there is no such problem.
To solve this problem, I used Fiddler to get the actual error code - in this case, a 403.1. This indicated that the executable for the service couldn't be run.
The actual problem ended up being that the ASP.NET version was set to 1.1, not 2.0+. So setting that to 2.0 resolved the 403 permission error.
Http 403 error is "Forbidden". There is something that is blocking access.
In cases where it worked at one point and then stopped, it is often a windows update that has tightend up the security.
Where is your WCF service installed?
What are the ACL's on these files?
What is the security context of your service? (Which account will be used to access the files)
Does that user have access to the files?