Skip to content

Conversation

yubiuser
Copy link
Member

@yubiuser yubiuser commented Apr 24, 2025

What does this PR aim to accomplish?:

Fix the logic in api.sh. I noticed we had the leftover API_PORT which was intended to signal if we found a responding api. The check for emptiness war wrong in the first place (using -n instead of -z).

This PR fixes the logic by better naming the variable and explicitly setting it to true/false.


By submitting this pull request, I confirm the following:

  1. I have read and understood the contributors guide, as well as this entire template. I understand which branch to base my commits and Pull Requests against.
  2. I have commented my proposed changes within the code and I have tested my changes.
  3. I am willing to help maintain this change if there are issues with it later.
  4. It is compatible with the EUPL 1.2 license
  5. I have squashed any insignificant commits. (git rebase)
  6. I have checked that another pull request for this purpose does not exist.
  7. I have considered, and confirmed that this submission will be valuable to others.
  8. I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
  9. I give this submission freely, and claim no ownership to its content.

  • I have read the above and my PR is ready for review. Check this box to confirm

@yubiuser yubiuser requested a review from a team April 24, 2025 07:10
@yubiuser yubiuser mentioned this pull request Apr 25, 2025
1 task
Signed-off-by: Christian König <github@yubiuser.dev>
Copy link
Member

@dschaper dschaper left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the API isn't available then immediately write to log exit, no need to create a local variable to track.

@yubiuser
Copy link
Member Author

yubiuser commented May 4, 2025

We need the variable because it is set within the loop. The chaos_api_list we iterate over can contain multiple URLs and we need to check if we find at least one working API. Only if we exit the loop because we finished iteration and apiAvailable is still false we know that none of the URLs returned by chaos_api_list did work. However, if we find at least one working API, we also exit the loop prematurely and apiAvailable will be true, skipping the exit.

@yubiuser yubiuser requested review from dschaper and a team May 4, 2025 12:14
@dschaper
Copy link
Member

dschaper commented May 4, 2025

Okay, then the logic is off here.

I don't like having ! tests for things like this, it's backwards logic and doesn't account for changes in the API response.

What happens if the API is changed to return a 403?

Do we currently keep iterating through the list of URLs even after we find an open endpoint?

Do we track which URL was 200, or which URL was 401?

@dschaper
Copy link
Member

dschaper commented May 4, 2025

  1. Get list of URLs
  2. Check for response from URL in URLs.
  3. if 200 then use that URL and stop looking
  4. else if 401 then check if we can authenticate
  5. if we can't then continue
  6. if were at the end of the list then we haven't found a valid URL, log and exit.

@yubiuser
Copy link
Member Author

yubiuser commented May 4, 2025

Do we currently keep iterating through the list of URLs even after we find an open endpoint?

No.

apiAvailable=true
break

Do we track which URL was 200, or which URL was 401?

Yes. As we exit the loop once we found a responding URL, it's the one set at this moment in API_URL. We know if we got 200 or 401 by setting

if [ "${authStatus}" = 200 ]; then
# API is available without authentication
needAuth=false


Get list of URLs
Check for response from URL in URLs.
if 200 then use that URL and stop looking
else if 401 then check if we can authenticate
if we can't then continue
if were at the end of the list then we haven't found a valid URL, log and exit.

This is (almost) exactly what we do.


I don't like having ! tests for things like this, it's backwards logic and doesn't account for changes in the API response.

I see your point but we adhere to the HTTP return codes used everywhere. I can reverse the logic to explicitly check for 200 and 400 instead, but this would change nothing if FTL decides to change the response code.

@dschaper
Copy link
Member

dschaper commented May 4, 2025

I like explicit, if we need 200 or 401 then check for 200 or 401.

Read through

        # Test if http status code was 200 (OK) or 401 (authentication required)
        if [ ! "${authStatus}" = 200 ] && [ ! "${authStatus}" = 401 ]; then

And tell me what we're looking for, compared to (pseudocode-ish):

# Test if http status code is 200 (OK)
if [ "${authStatus}" = 200 ]; then
    needAuth=false
# Test if http status is 401 (Auth required)
elif [ "${authStatus}" = 401]; then
    # Check if 2FA is required
    needTOTP=$(echo "${authData}"| jq --raw-output .session.totp 2>/dev/null)
else
    # Remove the first URL from the list
    local last_api_list
    last_api_list="${chaos_api_list}"
    chaos_api_list="${chaos_api_list#* }"

    # If the list did not change, we are at the last element
    if [ "${last_api_list}" = "${chaos_api_list}" ]; then
        # Remove the last element
        chaos_api_list=""
       
        # List of URLs is empty and we have not found a valid URL
        echo "API not available. Please check FTL.log"
        echo "Exiting."
        exit 1

    fi
fi

Signed-off-by: Christian König <github@yubiuser.dev>
@yubiuser
Copy link
Member Author

yubiuser commented May 4, 2025

Logic is now reverted.

@dschaper dschaper merged commit 3c6c3d3 into development May 11, 2025
16 checks passed
@dschaper dschaper deleted the fix/api_port branch May 11, 2025 15:43
@PromoFaux PromoFaux mentioned this pull request May 30, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants