I'm trying to create new CMIS type using Workbench and always get the message:
"CMIS Exception: permissionDenied".
Does anybody has experience with NemakiWare how to solve this problem?
Thank you in advance.
I was getting this misleading message using a different CMIS-compliant repository (Alfresco) when referencing a deprecated link structure for the CMIS endpoint.
i.e., older versions of Alfresco provide an AtomPub endpoint like this:
http://cms.mysite.com/alfresco/cmisatom
Newer versions implement this structure:
http://cms.mysite.com/alfresco/api/-default-/public/cmis/versions/1.0/atom
If I attempted to access the former link, I'd get an "access denied" message. Make sure your endpoint fits the structure appropriate to the version of NemakiWare you're running.
Related
I realized that when I try to access one of the paths defined in my swagger 2.0 with an incorrect method (ie. GET instead of POST), I receive the following message:
{"message":"Route defined in Swagger specification (/movie) but there is no defined get operation.","allowedMethods":["POST"]}
I am getting the above error. I am using nodeJs server and What i will add into the nodejs file.. Anyone help me how to solve this error.
I'm trying to run Heat Clinic 6.0.1 locally following getting started tutorial: https://www.broadleafcommerce.com/docs/core/current/getting-started/running-locally
I managed to run admin and site but not the API project. The application starts without problems but when I go to http://localhost:8082/api/v1/swagger-ui.html I get a 404. In the log I see this exception:
javax.servlet.ServletException: Circular view path [error]: would dispatch back to the current handler URL [/error] again. Check your ViewResolver setup! (Hint: This may be the result of an unspecified view, due to default view name generation.)
Also trying to log in directly in the API with user broadleafapi and password gives 404.
My environment: Windows 10, jdk 8, maven 3.6
What's wrong? Can you help me? Thank you
Thanks for the report. I reproduced this and it looks like that with the update to Spring Boot 2.0, we did not appropriately override the updated property that specifies the servlet location to embedded Tomcat. Thus, when you went to /api/v1/swagger-ui.html, the application treats it exactly like that URL which is what gave the 404.
Setting the server.servlet.contextPath=/api/v1 property appropriately stripped off this path as part of the servlet context and resolved the 404.
I tested around a bit and was able to 'Authorize' the app (button at the top right of the Swagger page) with the credentials information that get spit out in the logs:
Basic auth configured with user broadleafapi and password: <<generated>>
then I was able to hit the API endpoints.
The changes you will need to make locally in your project to consume the fix are at https://github.com/BroadleafCommerce/DemoSite/commit/422d1cdc37f847afd8bec0be477ab784cbad2e9d#diff-991c59b6dbb0f619b8570d8f8779eaddR11. You will notice that I moved the original definition in default.properties over to common.properties and I recommend that you do the same. To be clear, follow these steps:
Delete the server.servlet.contextPath entry in `api/src/main/resources/runtime-properties/default.properties
Change server.servletPath in api/src/main/resources/runtime-properties/common.properties to server.servlet.contextPath
Thanks for trying out Broadleaf and the report, sorry for the rough early start!
Currently using RestSharp V106.1.0 as well a v2.1.8
While attempting to integrate docusign with our application I received an error off of the loginAPI:
string accountId = loginApi(username, password, integratorKey);
Receiving this error
{"Method not found: 'RestSharp.IRestRequest RestSharp.RestRequest.AddFile(System.String, System.Action`1, System.String, System.String)'."}
I have verified all of the parameters have the correct value and I was able to recreate a working API usage in a brand new project without prior packages installed. This leads me to think it is the version of RestSharp that is giving me this issue.Based on research about others having this issue it was an issue of the library change within updates.
Is there a specific version that is required as the dependancies for Docusign Package in visual studio doesn't mention a Restsharp version requirement?
Thank you in advance.
I'm trying to access the result of a GET request provided by Azure, as shown in the example : https://msdn.microsoft.com/sv-se/library/azure/dn820159.aspx
My problem is that the api-version is a mandatory argument, but I have no idea about what to write inside. I'm a bit lost with the Azure Batch documentation, it doesn't seem to be complete.
I found something in an Azure webpage : https://azure.microsoft.com/en-us/documentation/articles/search-api-versions/ and the api-version was api-version=2015-02-28. However, if I try it in my browser, I have this answer : "key":"Reason","value":"The specified api version string is invalid".
Any idea of what I can put inside the api-version parameter ?
Have a look here
As the time of this writing
The version of the Batch API described here is '2016-07-01.3.1', and
using that version is recommended where possible.
Earlier versions include '2016-02-01.3.0', '2015-12-01.2.1',
'2015-11-01.2.1', '2015-06-01.2.0', '2015-03-01.1.1', and
'2014-10-01.1.0'.
So try specifying '2016-07-01.3.1'
I setup the Social Business Toolkit against our development system. All APIs are working correct, except for the Blog and Activities API.
For both i recieve within the Java APIs the following error:
org.apache.http.conn.EofSensorInputStream cannot be cast to org.w3c.dom.Document
The blog request url from the sbt is:
http://example.com/service/proxy/connections/blogs/homepage/feed/blogs/atom?ps=5&dojo.preventCache=13
But correct would be:
http://example.com/service/proxy/connections/blogs/atom?ps=5&dojo.preventCache=13
Any idea why that happens?
The blog path is customizable per each IBM Connection installation: to support different blogs homepages, there is a parameter exposed on the BlogService API.
To change the default, try:
BlogService svc = ...
svc.defaultHomepageHandle = "";
Lorenzo's answer is correct, most installations use homepage as the blog handle, but you can configure it using the defaultHomepageHandle member variable in the BlogService.
Just a brief comment, maybe it's better to use the setHomepageHandle() method instead.