GitHub Action fails upon authentication with SWORD API

[JR-1991]

After merging the recent pull request #201 by @shoeffner, one test fails even though all checks have passed in the pull request CI, which is quite unexpected. I am opening this issue to keep track of this.

Failed run

=========================== short test summary info ============================
FAILED tests/api/test_api.py::TestApiToken::test_sword_api_can_authenticate - assert 400 == 200
 +  where 400 = <Response [400 Bad Request]>.status_code
================== 1 failed, 79 passed, 65 warnings in 21.12s ==================

[JR-1991]

I dont know why, but it seems like there are some bots spamming sketchy Mediafire links to PRs (see https://github.com/microsoft/vscode/issues/226578 for sth similar). I have hidden the comments and advise to NOT click the links supplied.

[shoeffner]

Reported the spam GitHub. Can have a look at the issue soon, maybe tonight. Otherwise in the upcoming days.

On Mon, Aug 26, 2024, 12:05 Jan Range @.***> wrote:

I dont know why, but it seems like there are some bots spamming sketchy Mediafire links to PRs (see microsoft/vscode#226578 https://github.com/microsoft/vscode/issues/226578 for sth similar). I have hidden the comments and advise to NOT click the links supplied.

— Reply to this email directly, view it on GitHub https://github.com/gdcc/pyDataverse/issues/213#issuecomment-2309838490, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOAOD2EFLFPWAGIWLC63YLZTL4YPAVCNFSM6AAAAABNDMFTDCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBZHAZTQNBZGA . You are receiving this because you were mentioned.Message ID: @.***>

[shoeffner]

I checked out the main branch but cannot reproduce the test failure locally with the docker-compose setup. Maybe the CI runs against a different Dataverse version? I'll try against the dataverse demo instance later...

[JR-1991]

I can confirm that I wasn't able to reproduce the error using a local instance. To investigate further, I created a fork and hard-coded DV_VERSION: 6.3 into the workflow to see if the action might be using version 6.4 instead, since some tests explicitly check the DV version. Interestingly, all tests, except the one failing in this issue, ran successfully.

I also tested against https://demo.dataverse.org, and the test failed there as well. I looked into it further and, out of curiosity, I wrote a script to perform the test "manually".

auth = httpx.BasicAuth("<TOKEN>", "")
response = httpx.get(
     "https://demo.dataverse.org/dvn/api/data-deposit/v1.1/swordv2/service-document",
     auth=auth,
)

This is where I discovered that the SSL certificate for demo.dataverse had expired, causing the request to fail since httpx typically verifies if a certificate is valid. @pdurbin you may already be aware of this, but I am tagging you here. While this resolved the issue for demo.dataverse, I am not comfortable with setting verify=False, as it defeats the purpose of SSL. At least this confirms that the code itself is functioning correctly, but I’m still puzzled as to why it only fails within the GitHub Workflow.

I didn't stop there and applied the "manual" test from earlier into a fork of mine, and voilà, everything worked. Here is the test I overwrote in my fork:

https://github.com/gdcc/pyDataverse/blob/ba994e727947846c97760246b881e1c9768f37ce/tests/api/test_api.py#L221-L236

For the grand finale, I restored everything and printed the actual URL being used, and believe it or not, the whole error stemmed from a wrong URL where there was // instead of / in http://localhost:8080//dvn/api/data-deposit/v1.1/swordv2/service-document. I'm relieved it was something so simple 😁

[pdurbin]

the SSL certificate for demo.dataverse had expired

Yes, sorry, our wildcard cert expired. We are rolling out the new one now. The guides server has been fixed. demo soon, I suspect.

[pdurbin]

Weird about the double slash. Thanks for fixing it! 🎉