You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(This is more of an hosting configuration request than it is an iOS SDK one, but I'm not currently aware of a better place to post this, so here we go.)
New Feature
The CDN (which looks to be Cloudfront, based on the HTTP responses I'm seeing) hosting the MapBox SDK artifacts should return WWW-Authenticate: Basic realm=... header alongside 401 responses.
Why
The current standard of configuring ~/.netrc files for authenticating with MapBox's CDN works well for personal development environments, but can be somewhat brittle in CI pipelines, especially those that run on bare metal without containerization.
One potential alternative here is to allow Mapbox's various Package.swifts to accept credentials from environment variables and bake them into the URLs themselves. As an example, the following code from mapbox-common-ios's Package.swift:
This change would continue to be fully backwards compatible with having a ~/.netrc file, but also allow users to authenticate in CI using only environment variables. This is a code change I myself would be up to volunteer contributing to the various open source repositories.
However, SPM has hitch necessitating the need for the aforementioned Cloudfront addition.
Even though the manual curl https://<username>:<password>@api.mapbox.com/downloads/v2/mapbox-common/releases/ios/packages/24.2.1/MapboxCommon.zip command works as expected, SPM will proactively strip out the provided URL's embedded credentials, perform the GET request, and only upon a 401 response code AND the presence of the WWW-Authenticate: Basic realm=... header will it retry the request with the previously stripped credentials Base64-encoded into the Authorization header.
Based on some cursory HTTP debugging, it looks like the Cloudfront instance Mapbox's binary artifacts are distributed from do not include the WWW-Authenticate: Basic realm=... header upon 401s.
The text was updated successfully, but these errors were encountered:
(This is more of an hosting configuration request than it is an iOS SDK one, but I'm not currently aware of a better place to post this, so here we go.)
New Feature
The CDN (which looks to be Cloudfront, based on the HTTP responses I'm seeing) hosting the MapBox SDK artifacts should return
WWW-Authenticate: Basic realm=...
header alongside 401 responses.Why
The current standard of configuring
~/.netrc
files for authenticating with MapBox's CDN works well for personal development environments, but can be somewhat brittle in CI pipelines, especially those that run on bare metal without containerization.One potential alternative here is to allow Mapbox's various
Package.swift
s to accept credentials from environment variables and bake them into the URLs themselves. As an example, the following code frommapbox-common-ios
'sPackage.swift
:would be transformed into:
This change would continue to be fully backwards compatible with having a
~/.netrc
file, but also allow users to authenticate in CI using only environment variables. This is a code change I myself would be up to volunteer contributing to the various open source repositories.However, SPM has hitch necessitating the need for the aforementioned Cloudfront addition.
Even though the manual
curl https://<username>:<password>@api.mapbox.com/downloads/v2/mapbox-common/releases/ios/packages/24.2.1/MapboxCommon.zip
command works as expected, SPM will proactively strip out the provided URL's embedded credentials, perform the GET request, and only upon a 401 response code AND the presence of theWWW-Authenticate: Basic realm=...
header will it retry the request with the previously stripped credentials Base64-encoded into theAuthorization
header.Based on some cursory HTTP debugging, it looks like the Cloudfront instance Mapbox's binary artifacts are distributed from do not include the
WWW-Authenticate: Basic realm=...
header upon 401s.The text was updated successfully, but these errors were encountered: