When I call /bulkload with a graphml file, I get a 502 Server Error: Bad Gateway. When I check the response it says
Name cannot be in protected namespace: label, status_code=500
How can I fix that ?
IBM graph has some restricted attribute/property names that can't be used. Here's a list of these restricted names The following property key names are restricted: "key", "vertex", "edge", "element", "property", and "label".
Here's a link to the documentation https://ibm-graph-docs.ng.bluemix.net/api.html
Change the attributed name you have from label to anything other than the restricted name and that should work
Related
I'm trying to call Access package assignment approval update via MSGraph Beta API (Java 0.51.0-SNAPSHOT). The call fails with following error:
2022-08-26 22:32:44.239 ERROR 10208 --- [nio-9999-exec-4] global : CoreHttpProvider[sendRequestInternal] - 408Graph service exception
2022-08-26 22:32:44.239 ERROR 10208 --- [nio-9999-exec-4] global : Throwable detail: com.microsoft.graph.http.GraphServiceException: Error code:
Error message: Only user tokens are supported
PATCH https://graph.microsoft.com/beta/identityGovernance/entitlementManagement/accessPackageAssignmentApprovals/aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa/steps/bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb
SdkVersion : graph-java/v0.51.0
[...]
403 : Forbidden
[...]
[Some information was truncated for brevity, enable debug logging for more details]
Based on the error message can I think, that Application tokens are not really supported, but the strange thing is, that I can call Access package assignment approval get without any issue. I have of course delegated the permission EntitlementManagement.ReadWrite.All to the Application user.
I tried to reproduce the same in my environment using Graph Explorer and got the below results:
I am able to retrieve the properties of an approval object successfully like this:
GET https://graph.microsoft.com/beta/identityGovernance/entitlementManagement/accessPackageAssignmentApprovals/<id>
Response:
To update those properties, I ran the same query as you like below, and it got updated successfully:
PATCH https://graph.microsoft.com/beta/identityGovernance/entitlementManagement/accessPackageAssignmentApprovals/<id>/steps/<id>
{
"reviewResult": "Approve",
"justification": "Please approve"
}
Response:
Make sure to pass 'Request body' with the PATCH query. Please check whether you are giving correct id's or not in the query.
The <id> before /steps/ in the query is the id of accessPackageAssignmentRequest that is in PendingApproval State.
To get that id, you can run the below query:
GET https://graph.microsoft.com/beta/identityGovernance/entitlementManagement/accessPackageAssignmentRequests?$expand=requestor($expand=connectedOrganization)&$filter=(requestState eq 'PendingApproval')
Response:
The <id> after /steps/ in the query is the step id that I got by running below query:
GET https://graph.microsoft.com/beta/identityGovernance/entitlementManagement/accessPackageAssignmentApprovals/<id_that_you _got_in_above_query>
Response:
UPDATE
Please note that, you cannot update Access package assignment approval using Application permissions. Application permissions are not supported for PATCH query.
You can refer this MsDoc to confirm that like below:
So, it will only work if you login with work or school account(personal-login)
I am getting 403 errors with sp-rest-proxy. I was originally using the “User Credentials” strategy which allowed me to GET data, but not POST it. So now I’m am trying the “Addin only permissions”. My I.T. team was able get the app registered for me. but I am still receiving the below error now even with GET.
Error Details:
{
"readyState": 4,
"responseText": "{\"error\":{\"code\":\"-2147024891, System.UnauthorizedAccessException\",\"message\":{\"lang\":\"en-US\",\"value\":\"Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))\"}}}",
"responseJSON": {
"error": {
"code": "-2147024891, System.UnauthorizedAccessException",
"message": {
"lang": "en-US",
"value": "Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))"
}
}
},
"status": 403,
"statusText": "Forbidden"
}
Things I suspect I messed up on:
I strongly think its my server/private config I have the following…
const RestProxy = require('sp-rest-proxy');
const settings = {
configPath: './config/private.json',
port: 8081,
};
const restProxy = new RestProxy(settings);
restProxy.serve();
and private (not the actual values I am using expect for "strategy" )
{
"siteUrl": "https://ORGANIZTION.sharepoint.com",
"strategy": "OnlineAddinOnly",
"clientId": "0000000-000000-000000-0000-00000000",
"clientSecret": "000000000000000000000000000000",
"realm": "00000-0000-0000-0000-000000"
}
I couldn’t find much on the “strategy” value on the sp-rest-proxy or the node-sp-auth side of the documentation. I can assume its OnlineAddinOnly but I’m not able to find the specific syntax for what possible values this attribute expects. I also noticed that the “clientSecret” is changing once I run the server, I assume this is an intentional encryption.
During the App registration phase (step 5 of this https://github.com/s-KaiNet/node-sp-auth/wiki/SharePoint%20Online%20addin%20only%20authentication) I had the IT folk set the “right” attribute in AppPermissionRequests to “Write” instead “FullControl”, I noticed that “FullControl” seems to be used in most example though I wasn’t sure if it was required. Can anyone confirm that?
[Edit: confirmed this is not the issue by setting this to FullControl]
Intention:
I am trying to build an internal data management tool that only needs to work on localhost to get manipulate and replace json files in my teams SharePoint. (just in a nice way so that non-coders can do this). The “sp-rest-proxy” library seems to be what I need to implement the REST API effectively in react.
As far as I know, SharePoint app-only access is disabled by default. You need to ask your administrator to enable it by running the following command:
set-spotenant -DisableCustomAppAuthentication $false
The answer likely in the XML AppPermissionRequests. The creator of the library was able to point me to a better example and I had noticed some differences we had a different scope value and no AllowAppOnlyPolicy adding these seems to have fixed most of the issue. I am able to confirm that I can now do GET.
I am still having issues with GetFolderByServerRelativeUrl and using the to add/replace files but I am not sure that is related and will treat it as a separate issue as it may not be related to sp-rest-proxy or node-sp-auth
the correct AppPermissionRequests XML should be this ->
and as #Michael Han_MSFT mentioned you should ensure that DisableCustomAppAuthentication is set to false
<AppPermissionRequests AllowAppOnlyPolicy="true">
<AppPermissionRequest Scope="http://sharepoint/content/tenant" Right="FullControl" />
</AppPermissionRequests>
We are struggling to import certain files into Solr occasionally. It seems like certain documents have weird meta data (values), not sure if it might be from eccentric word processor or something else. See two examples here:
Type: Solarium\Exception\HttpException
Message: Solr HTTP error: OK (400)
{"responseHeader":{"status":400,"QTime":49},"error":{"metadata":["error-class","org.apache.solr.common.SolrException","root-error-class","java.lang.NumberFormatException"],"msg":"ERROR: [doc=3932487729] Error adding field 'brightness_value'='6.18' msg=For input string: \"6.18\"","code":400}}
And
Type: Solarium\Exception\HttpException
Severity: error --> Exception: Solr HTTP error: OK (400)
{"responseHeader":{"status":400,"QTime":72},"error":{"metadata":["error-class","org.apache.solr.common.SolrException","root-error-class","java.lang.NumberFormatException"],"msg":"ERROR: [doc=16996] Error adding field 'version'='5.3.1' msg=For input string: \"5.3.1\"","code":400}}
How do we prevent these issues? We are not in control of the documents, so need to fix it on the server.
Define the field type explicitly in the schema instead of relying on Solr to create the field type for you - the first document that contains the field will make Solr guess the type of the field, and if later documents doesn't match the same, expected format, you'll get an error like this.
Always define the schema for a collection when using it in production or in an actual application - the schemaless mode is really neat for prototyping and experimenting, but in an actual application you want the types to be well defined.
I am trying to get SPTTrack object from url using Spotify iOS SKD v10beta.
Somehow, it returns an error, like :
Error Domain=com.spotify.ios-sdk Code=102 "No registered class for type 'artist'" UserInfo=0x7a644700 {NSLocalizedDescription=No registered class for type 'artist'}
Strange thing, that it has worked previously. I have found similar problem in getting the user.
What this error is related to? I have removed/added,linked spotify framework multiple times.
Ideas?
Error occurred because ObjC was not present at Other Linker Flags in frameworks/libraries/targets/project.
I want to ask what is the difference between DriveScopes.DRIVE_METADATA_READONLY and https://www.googleapis.com/auth/drive.readonly.metadata? In other words, what is the difference between
these two forms:
https://www.googleapis.com/auth/drive.metadata.readonly //DriveScopes.DRIVE_METADATA_READONLY
https://www.googleapis.com/auth/drive.readonly.metadata
When I was using service account for working with Drive API it takes me a long time to figure out, why my app was throwing unauthorized exception:
Uncaught exception from servlet
com.google.api.client.auth.oauth2.TokenResponseException: 403
{
"error" : "access_denied",
"error_description" : "Requested client not authorized."
}
The String constant DriveScopes.DRIVE_METADATA_READONLY was causing the exception. In which context should I use this constant?
That's clearly a mistake in the Java API client.
The API documentation states that the correct scope is :
https://www.googleapis.com/auth/drive.readonly.metadata
Whereas when you look at the latest javadoc (at the time of this answer), you get :
https://www.googleapis.com/auth/drive.metadata.readonly
You should ignore the DriveScopes constant and create your own constant, while the Google Drive team fixes this.