Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

V2ServerAPICalls: JFrog quirk flag should enable for Artifactory domains without "jfrog" in the domain #1530

Closed
3 tasks done
sean-r-williams opened this issue Jan 23, 2024 · 3 comments · Fixed by #1532
Closed
3 tasks done

Comments

@sean-r-williams
Copy link
Contributor

sean-r-williams commented Jan 23, 2024

Prerequisites

  • Write a descriptive title.
  • Make sure you are able to repro it on the latest released version
  • Search the existing issues.

Steps to reproduce

(Related to #1485 and #1526 - spinning off a separate issue at the request of @alerickson in #1485 (comment))

  • Purchase and install Artifactory on-premises, with a self-descriptive domain name (like artifactory).
  • Wait some time for JFrog to rearchitect Artifactory to "JFrog Platform" with component services like Artifactory, XRay, etc. (/s)
  • Register Artifactory/JFrog repository with PSResourceGet

Our Artifactory/JFrog instances all have local DNS name artifactory (plus some environment-specific DNS suffixes that are NDAed). In any case, we'd expect the Artifactory NuGet URLs to look something like https://artifactory.f.q.d.n/artifactory/api/nuget/v2/<feed-name>/ (replacing f.q.d.n) with the DNS suffix

Expected behavior

Microsoft.PowerShell.PSResourceGet.Cmdlets.V2ServerAPICalls._isJFrogRepo is true when PSResourceGet makes calls to Artifactory endpoints

Actual behavior

Microsoft.PowerShell.PSResourceGet.Cmdlets.V2ServerAPICalls._isJFrogRepo is false

Error details

N/A

Environment data

ModuleType Version    Name                                ExportedCommands                                             
---------- -------    ----                                ----------------                                             
Binary     1.0.1      Microsoft.PowerShell.PSResourceGet  {Find-PSResource, Get-InstalledPSResource, Get-PSResourceR...

Key   : PSVersion
Value : 5.1.19041.3803
Name  : PSVersion


Key   : PSEdition
Value : Desktop
Name  : PSEdition


Key   : PSCompatibleVersions
Value : {1.0, 2.0, 3.0, 4.0...}
Name  : PSCompatibleVersions


Key   : BuildVersion
Value : 10.0.19041.3803
Name  : BuildVersion


Key   : CLRVersion
Value : 4.0.30319.42000
Name  : CLRVersion


Key   : WSManStackVersion
Value : 3.0
Name  : WSManStackVersion


Key   : PSRemotingProtocolVersion
Value : 2.3
Name  : PSRemotingProtocolVersion


Key   : SerializationVersion
Value : 1.1.0.1
Name  : SerializationVersion

Visuals

N/A

@sean-r-williams
Copy link
Contributor Author

sean-r-williams commented Jan 23, 2024

Depending on the requirements of this specific class, it may be worth replacing hostname-/URL-based detection with an HTTP request to the root feed URL. (This call does not need to be authenticated.)

Artifactory's response (be it 2xx, 401, 403, or 5xx) will include one of the following HTTP headers in the response:

  • X-Artifactory-Id
  • X-Artifactory-Node-Id
  • X-Jfrog-Version

@sean-r-williams sean-r-williams changed the title v2 ServerAPICalls: JFrog quirk flag should enable for Artifactory domains without "jfrog" in the domain V2ServerAPICalls: JFrog quirk flag should enable for Artifactory domains without "jfrog" in the domain Jan 23, 2024
@alerickson
Copy link
Member

I didn't couldn't find X-Artifactory-Id, X-Artifactory-Node-Id, or X-Jfrog-Version in the HTTP Headers (using my test account), but did find <title>JFrog</title> in the response content.

@sean-r-williams do you happen to see <title>JFrog</title> in the content of your response as well?

@sean-r-williams
Copy link
Contributor Author

sean-r-williams commented Jan 23, 2024

@sean-r-williams do you happen to see <title>JFrog</title> in the content of your response as well?

@alerickson I don't, no. To clarify, I'm talking about a request to the root URL of the feed (i.e. the one users provide when registering the repository) - that is, something like https://artifactory.f.q.d.n/artifactory/api/nuget/v2/psgallery-nuget-local. I don't see the aforementioned X-* headers when hitting the domain root (https://artifactory.f.q.d.n), even though it is a selfhosted JFrog Platform/Artifactory instance.

I do see <title>JFrog</title> when GETting the domain root, but I would caution against using that for any heuristics. If Artifactory were hosted behind a reverse-proxy (or similar) under a specific VPath, the domain-root might "point to" a service other than JFrog and that detection would break.

For the sake of completeness, the response content when GETing https://artifactory.f.q.d.n/artifactory/api/nuget/v2/psgallery-nuget-local (the root URL of the feed) looks like this:

  • Authenticated:
    <?xml version="1.0" encoding="utf-8"?>
    <!--
     ~
     ~ Copyright 2016 JFrog Ltd. All rights reserved.
     ~ JFROG PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
     -->
    
    <service xmlns="http://www.w3.org/2007/app" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:app="http://www.w3.org/2007/app" xml:base="https://artifactory.f.q.d.n/artifactory/api/nuget/psgallery-nuget-local">
       <workspace>
           <atom:title>Default</atom:title>
           <collection href="Packages">
               <atom:title>Packages</atom:title>
           </collection>
       </workspace>
    </service>
  • Unauthenticated:
    {
      "errors": [
        {
          "status": 401,
          "message": "Unauthorized"
        }
      ]
    }

In both cases, headers look something like this (plus WWW-Authenticate: Basic realm="Artifactory Realm" for the 401):

X-JFrog-Version: Artifactory/7.59.12 75912900
X-Artifactory-Id: 0123456789abcdef0123456789abcdef01234567
X-Artifactory-Node-Id: artifactory02
Transfer-Encoding: chunked
Date: Tue, 23 Jan 2024 06:35:13 GMT
Content-Type: application/json

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants