Hello,
I am trying to populate a REST Option List, whose contents would come from a json file stored in GitLab (I am perfectly able to populate other REST OptionLists coming from other sources).
The GitLab REST API allows you to get a raw file from a repo via an endpoint where the path to the file is URL encoded.
Example: if the file myFile.json
is in GitLab in the config
folder of ProjectA (path: ProjectA/config/myFile.json
), the endpoint to invoke would contain the pathfile “config/myFile.json
” URL encoded as “config%2Fmyfile.json
”
This ends up in a URL of the form:
https://mygitlab/gitlab/api/v4/projects/5/repository/files/config%2FmyFile.json/raw?ref=main' --header 'PRIVATE-TOKEN: glpat-xxxxxxxxxxxxxxxxxxxx'
I can get data with that URL from Postman and curl, and I can also invoke other GitLab endpoints from the Morpheus REST OptionList that do not require encoding (e.g. the endpoint to get a list of projects).
So I guess the reason for failure is the encoding character %2F.
Is there a way to overcome this?
Thanks,
Paolo
Hi, It looks like the %
symbol is itself being encoded resulting in this %252F
in the request.

Are the json files not accessible directly from the repository by obtaining their raw URL there? In my brief testing all the files present with the standard “/” path part separation when going that route.
Hello Ollie,
thanks for your reply.
If you mean the one you can get from the browser by selecting the “Open Raw” icon, then it does not work. I guess that using that url requires a different authentication mechanism (the REST API requires an access token). I tried setting “Basic authentication” and usr/pwd, but no way (not even from Postman/curl).
It’s not a bug, but I guess you could add an idea to disable the request encoding in the option list settings - that seems like it would prevent this double encoding - check out the ideas section of this forum.
In the meantime, if the JSON file has to be used and has to be accessed in this way, then maybe script a simple webserver that will get it and serve it to Morpheus at an endpoint on the webserver.
That’s one way.
Another way, could be to script an option source plugin.
With both those approaches you’d have full control over the client code that called out to the Gitlab REST endpoint.
Ok Ollie, thanks for the suggestions. I will try one of the options.
Kind regards,
Paolo
1 Like