Get on oslc query base returns 403 Forbidden from DNG
![]() I've received 4 oslc query bases from the services.xml document identified in the Service Provider catalog returned from DNG (6.0.6.1). Three of these query bases work without issue. The fourth one, against the project area, returns 403 Forbidden. The response body also contains - CRRRS1602W The operation is forbidden. The administrator can only tell me that I have Author permission. Has anyone else seen this issue? Am I doing something wrong? |
Accepted answer
3 other answers
![]() There could be a number of things that cause a 403 error. This error can mean that you have a wrong value in the query or in the headers of the REST call. One way to find out what is happening is to look in the rm.log file on the DNG server. There may be an error logged that will specify what is wrong. |
![]() The administrator said he "cleaned up LQE" and my query base request started working without issue. Comments Any idea what he cleaned up in LQE? What has this issue to do with LQE? I don't know what he cleaned up, but it looks like the fix was only temporary. The 403 showed up again a few days later. Currently, using the same query base url, DNG is returning 400 with java.lang.NullPointerException in the detailed message. We've been having indexing issue. I wonder if this exception is related. But all the other query base url's work. DOORS Next OSLC query doesn't go anywhere near LQE so no relation to LQE indexing. If DNG indexes are having problems then that could affect query.
If you're using configurations are you including the configuration in header vvc.configuration in all your GETs (including for the services.xml because this is component-specific)?
As I said on your question, if you want more help you'll have to be a lot more specific with details of your actual request - suggest you edit a (host-obfuscated) full encoded URL you're GET-ing from into your question with the headers you've applied.
There's an example of a full query URL in my answer to this question https://jazz.net/forum/questions/273866/how-to-create-a-oslc-query-to-download-a-artifact-of-type-document-in-dng The error 403 I get so far only on querying the requirements collections.
I get the queries through
'<host>/rm/oslc_rm/<projectid>/services.xml'. From there I use the following 3 OSLC queries:
1) requirement collections = on all project areas I get Error 403 "CRRRS1602W The operation is forbidden". There is no log entry in rm.log created.
curl -X GET -k -H 'OSLC-Core-Version: 2.0' -H 'Accept: application/rdf+xml' -i '<server>/rm/views?oslc.query=true&projectURL=<server>/rm/process/project-areas/<projectid>'
Any idea, on how to find the root cause, or how to fix this?
2) get list of views = ok, except a view name contains German umlauts (äöü). In this case you get Error 400 "com.hp.hpl.jena.shared.JenaException: org.apache.xerces.impl.io.MalformedByteSequenceException: Invalid byte 1 of 1-byte UTF-8 sequence."
3) get folder list = ok in all project areas.
Hi Donat
> requirement collections = on all project areas I get Error 403 "CRRRS1602W
Most likely you're not authenticated. To authenticate using curl try the steps in the answer here https://jazz.net/forum/questions/176102/how-to-login-to-jazz-team-server-using-rest-client making sure to pass the auth cookies on in subsequent curl requests.
Also curl login described in the question here https://jazz.net/forum/questions/81935/using-curl-command-line-to-monitor-performance
Create a new question if you still can't get it working.
HTH
Ian
showing 5 of 6
show 1 more comments
|
![]() This error indicates that the server has determined that you are not allowed access to the thing you've requested, either on purpose or due to a misconfiguration . It's probably because the site owner has limited access to it and you don't have permission to view it. The vast majority of the time, there's not much you can do to fix things on your (*client) end. There are four common causes for 403 Forbidden error (server side) . Here they are listed from most likely to least likely:
If authentication credentials were provided in the request, the server considers them insufficient to grant access. The client SHOULD NOT automatically repeat the request with the same credentials. The client MAY repeat the request with new or different credentials. However, a request might be forbidden for reasons unrelated to the credentials.
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
You'll have to be a lot more specific to get any more help because there are very many ways of making a bad request. What were the oslc:resourceType entries in that query capability? What request (GET/POST/PUT/etc.) did you make? What headers did you add? What query did you add to the query base? Did you fully escape the query? What tool did you use to make the request?