| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Codecov Report
@@ Coverage Diff @@
## main #2149 +/- ##
=======================================
Coverage 95.46% 95.46%
=======================================
Files 81 81
Lines 5353 5362 +9
=======================================
+ Hits 5110 5119 +9
Misses 243 243
Flags with carried forward coverage won't be shown. Click here to find out more.
|
Sorry, something went wrong.
|
I wonder if this would be better to be a config option? As probably the most likely case when this occurs is that something is wrong with their config. |
Sorry, something went wrong.
do you mean by set the config as parameter in class Gitlab, eg: keep_base_url=True, once they have the same case then just set it as True ? |
Sorry, something went wrong.
|
Thanks for the work here @iomarmochtar! Have a look at #1978 as well, which covers mostly the same topic. I agree with John we should at least not completely blindly follow either the server or the client-provided URL when there is a mismatch, hence my proposal in the issue above: I think we should issue a warning instead, unless explicitly configured to follow the base URL, and only then reconstruct the URL. Could we add that here? 🙇 Thanks again! For context: I actually would consider this approach a misconfiguration of the external_url, at least until GitLab supports multiple urls. E.g. the way your admins have configured it does not really scale - if your devs use other tech you'll have to implement this in the node gitbeaker library, in the terraform GitLab provider, and other libraries/apps, since most of these follow the link headers. Instead I think they should use clone_url in the runner config (which was designed for this purpose), and if needed have additional proxying done in front of specific runner endpoints. Because this also affects other aspects including many other types of links that GitLab returns in its API responses. |
Sorry, something went wrong.
|
@iomarmochtar would you still like to work on this as an optional parameter as discussed above? |
Sorry, something went wrong.
|
thanks you for remind me @nejch ,almost forgot to continue it due office task. let me try in this weekend. |
Sorry, something went wrong.
|
push as requested, please review it @nejch @JohnVillalovos |
Sorry, something went wrong.
There was a problem hiding this comment.
Thanks again @iomarmochtar. I have a few small comments
Sorry, something went wrong.
|
Thanks @iomarmochtar. I have some ideas to reuse this elsewhere that I think are outside the scope of this PR, so I'll merge this as is, and I will do a little refactor after. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Background
To enhance HTTP security our Gitlab is fronted by IAP for example https://gitlab.tools.domain.io but for internal communication from runner to Gitlab API we create another endpoint that protected by firewall rules so then it only can be accessed from certain IP only, for example https://runner.gitlab.tools.domain.io/ it actually using the reverse proxy that in the upstream destination will set Host header to the original one (gitlab.tools.domain.io).
But when we run a python script inside Gitlab pipeline to the endpoint (runner.gitlab.tools.domain.io) and pass argument all=True or iterator=True for loop all the data to all page will returning the base url as gitlab.tools.domain.io whereas it will causing the error due the request will be blocked by IAP.
Expected
The base url will be persist same as the first time set in the next url so the request will be expected goes as the first page when using pagination iterrator (all=True).
Fix
This MR will make sure the base in next url is the same. It's been tested in my case and working as expected.