fix: allow insecure connections in iOS WidgetExtension

[made2k]

Description

This is a change to the WidgetExtension bundle for the iOS application to allow insecure connections. It mirrors the same values allowed on the main iOS application, that is, it allows any insecure connection.

This fixes cases similar to #19829 where an insecure server connection is attempted and the connection is rejected by the system. Currently if the Immich server is accessed via a local IP (such as 192.169.1.100) there is no issue as iOS won't safeguard the connection with App Transport Security (ATS). But if using a hostname, and in my case, accessing via an insecure Tailscale host (ie http://tailscale.ts.net) the widget connection fails. By changing the App Transport Security setting for the WidgetExtension to match the Application setting, this issue is resolved.

There are other options for ATS, though with servers provided via user input, a more strict allowance may be hard to manage. Since the primary app bundle allows arbitrary loads, I don't see an issue with using that same setting for the widget bundle. If there's ever a change to the app bundle, we'd probably want to keep this mirrored as well.

Potentially Fixes #19829 though in the provided image in that issue, it appears the server is secured, though I am not able to verify.

How Has This Been Tested?

I compiled and ran the code, and reproduced the issue using my insecure hostname which redirects to my local URL. This loads fine in the app, but fails in the iOS widget. Digging in and running via Xcode I added a catch to where the error was occurring and received the log indicating the failure:

Error Domain=NSURLErrorDomain Code=-1022 "The resource could not be loaded because the App Transport Security policy requires the use of a secure connection." UserInfo={NSLocalizedDescription=The resource could not be loaded because the App Transport Security policy requires the use of a secure connection., NSErrorFailingURLStringKey=http://<SERVER_HOSTI>/api/search/random?sessionKey=<SESSION_KEY>, NSErrorFailingURLKey=http://<SERVER_HOSTI>/api/search/random?sessionKey=<SESSION_KEY>, _NSURLErrorRelatedURLSessionTaskErrorKey=(
    "LocalDataTask <46B07288-CF8D-46D8-9FA5-5052271CA038>.<1>"
), _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <46B07288-CF8D-46D8-9FA5-5052271CA038>.<1>, NSUnderlyingError=0x600000c20d80 {Error Domain=kCFErrorDomainCFNetwork Code=-1022 "(null)"}}

With this clear message, I made the requested change that mirrors the app bundle settings for this same configuration.

With the change in place, recompiling and running allows the widgets to refresh and show images as expected.

Checklist:

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation if applicable
• I have no unrelated changes in the PR.
• I have confirmed that any new dependencies are strictly necessary.
• I have written tests for new code (if applicable)
• I have followed naming conventions/patterns in the surrounding code
• All code in src/services/ uses repositories implementations for database calls, filesystem operations, etc.
• All code in src/repositories/ is pretty basic/simple and does not have any immich specific logic (that belongs in src/services/)

[bo0tzz]

This doesn't just permit more HTTP connections, but also has implications for HTTPS. If we're going to set it, it should be with a lot of care and discussion.

[bwees]

The main app has this key set so there shouldn't be any more HTTPS implications than what the main app already has @bo0tzz

[made2k]

@bo0tzz I agree that generally it can be a security topic to when setting a value like this. That said, it seems this was added pretty early on to the main app, and it hasn't been of concern yet.

I don't want to brush off your concerns. While the scope here may not be the best place to discuss, maybe a discussion could be started to look at less permissive set of ATS settings across the main app and the extensions using the API if such a solution is possible with the available ATS settings? I don't have a solution in mind for a more strict ATS that would work across the various custom server configurations that people would have. But if anyone may know of a way to handle that, we could look to update both this and the main app's ATS to reduce the permissive settings.

I wasn't aware this is already set on the main app.