It's all about the answers!

Ask a question

Get on oslc query base returns 403 Forbidden from DNG

doug weisenberg (2611) | asked Aug 22 '20, 11:15 a.m.

I've received 4 oslc query bases from the services.xml document identified in the Service Provider catalog returned from DNG (  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?

Ian Barnard commented Aug 27 '20, 9:52 a.m. | edited Aug 27 '20, 9:54 a.m.

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?

Accepted answer

permanent link
doug weisenberg (2611) | answered Mar 11 '21, 9:52 p.m.

 I think Ian got it.  My request was missing the configuration.  I added it to the request url and I did get a response; however, it took over an hour.  I'm a bit confused since the other oslc query bases did not require a configuration and did return appropriate information.  I has assumed these were going to my local configuration.     

Ralph Schoon selected this answer as the correct answer

Ian Barnard commented Dec 16 '21, 1:04 p.m.

Hi Doug - if you don't specify a configuration for an opt-in (i.e. with configuration management enabled) project then usually you get the default configuration - e.g. for project xyz that's the initial configuration "xyz Initial Stream" in the component called xyz. I haven't tried doing the folder queries without configuration but I'd have expected these to work the same way - perhaps they don't. Anyway bottom line is you should always provide a configuration on any query that could be affected by configurations, as either a header Configuration.Context with the unencoded configuration URL, or as query parameter (in the full URL) &oslc_config.context=(encoded URL)

3 other answers

permanent link
Kirk Woods (9158) | answered Aug 22 '20, 10:36 p.m.

 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.

permanent link
doug weisenberg (2611) | answered Sep 13 '20, 7:55 a.m.

The administrator said  he "cleaned up LQE" and my query base request started working without issue.

Guido Schneider commented Mar 10 '21, 12:23 p.m.

Any idea what he cleaned up in LQE? What has this issue to do with LQE? 

doug weisenberg commented Mar 10 '21, 12:53 p.m.

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.   

Ian Barnard commented Mar 11 '21, 3:37 a.m.

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.

Ian Barnard commented Mar 11 '21, 3:38 a.m.

Donat Hutter commented Mar 11 '21, 6:13 a.m.

The error 403 I get so far only on querying the requirements collections.
We are not using configurations. Installed RM version is v6.0.6.1, iFix013.

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: Invalid byte 1 of 1-byte UTF-8 sequence."

3) get folder list = ok in all project areas.

Ian Barnard commented Mar 12 '21, 3:24 a.m.

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 making sure to pass the auth cookies on in subsequent curl requests.

Create a new question if you still can't get it working.


showing 5 of 6 show 1 more comments

permanent link
lara brian (11) | answered Dec 22 '21, 1:39 a.m.

 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:

  • An empty website directory
  • No index page
  • Incorrect settings in the .htaccess file
  • Permission / Ownership error

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

Register or to post your answer.