immich-app/immich
1
0
Fork 0
mirror of https://github.com/immich-app/immich.git synced 2026-02-05 00:30:57 +03:00
Code Issues 12 Packages Projects Releases 10 Wiki Activity

[Feature]: Automatically add /api when signing into Mobile App #261

New Issue
Closed
opened 2026-02-04 19:09:48 +03:00 by OVERLORD · 16 comments
OVERLORD commented 2026-02-04 19:09:48 +03:00
Owner
Copy Link

Originally created by @mtthidoteu on GitHub (Sep 7, 2022).

Feature Details:

  • If user enters url without /api try both the url they enter, and if that fails (404, other relevant codes), try /api too
  • Remember the url that succeeded and update the entered URL so calls post-login use the correct URL

Platform

Mobile App

Originally created by @mtthidoteu on GitHub (Sep 7, 2022). ### Feature Details: - [ ] If user enters url without /api try both the url they enter, and if that fails (404, other relevant codes), try /api too - [ ] Remember the url that succeeded and update the entered URL so calls post-login use the correct URL ### Platform Mobile App
OVERLORD added the good first issue label 2026-02-04 19:09:48 +03:00
OVERLORD commented 2026-02-04 19:10:02 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Sep 7, 2022):

Good idea!

@alextran1502 commented on GitHub (Sep 7, 2022): Good idea!
OVERLORD commented 2026-02-04 19:10:04 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Sep 8, 2022):

I was sleeping on this last night. This would create an issue for users with a different endpoint directly proxy to /api of the server; for example, you can create a domain immichapi.yourdomain.com to proxy directly to your localip:2283/api. By automatically append /api to immichapi.yourdomain.com I think it will break that proxy method

@alextran1502 commented on GitHub (Sep 8, 2022): I was sleeping on this last night. This would create an issue for users with a different endpoint directly proxy to `/api` of the server; for example, you can create a domain `immichapi.yourdomain.com` to proxy directly to your `localip:2283/api`. By automatically append `/api` to `immichapi.yourdomain.com` I think it will break that proxy method
OVERLORD commented 2026-02-04 19:10:08 +03:00
Author
Owner
Copy Link

@zackpollard commented on GitHub (Oct 1, 2022):

We could have the app try both the base url and /api on login, and store what it actually connects with. The priority should be whatever the user enters, followed by trying /api

@zackpollard commented on GitHub (Oct 1, 2022): We could have the app try both the base url and /api on login, and store what it actually connects with. The priority should be whatever the user enters, followed by trying /api
OVERLORD commented 2026-02-04 19:10:16 +03:00
Author
Owner
Copy Link

@Mortein commented on GitHub (Dec 3, 2022):

How about a .well-known file on the webserver? Matrix does something similar for finding server back-end details for clients. https://spec.matrix.org/v1.5/client-server-api/#well-known-uri

/.well-known/immich/client

If the entered URL is the API, use that. Otherwise, look for the .well-known file, read the JSON, and use specified URL for the API.

@Mortein commented on GitHub (Dec 3, 2022): How about a .well-known file on the webserver? Matrix does something similar for finding server back-end details for clients. https://spec.matrix.org/v1.5/client-server-api/#well-known-uri /.well-known/immich/client If the entered URL is the API, use that. Otherwise, look for the .well-known file, read the JSON, and use specified URL for the API.
OVERLORD commented 2026-02-04 19:10:24 +03:00
Author
Owner
Copy Link

@jrasm91 commented on GitHub (Dec 14, 2022):

@Mortein That's a cool idea, which could make self-discovery a bit easier.

@jrasm91 commented on GitHub (Dec 14, 2022): @Mortein That's a cool idea, which could make self-discovery a bit easier.
OVERLORD commented 2026-02-04 19:10:36 +03:00
Author
Owner
Copy Link

@akoyaxd commented on GitHub (Jan 6, 2023):

I also would really like it.

Since it is related: adding https:// if only the hostname is suggested would also greatly improve UX for entering the Server URL.

@akoyaxd commented on GitHub (Jan 6, 2023): I also would really like it. Since it is related: adding https:// if only the hostname is suggested would also greatly improve UX for entering the Server URL.
OVERLORD commented 2026-02-04 19:10:42 +03:00
Author
Owner
Copy Link

@conneryn commented on GitHub (Jan 12, 2023):

I'm interested in taking a stab at implementing this.

I'm thinking an endpoint: /.well-known/immich with payload:

{
  "api": {
    "endpoint": "https://api.example.com/"
  }
}

Re: auto-adding https if missing. This is easy enough implement, but I wonder if it adds too many special cases? And the UI already informs the user that http/s is required, so the UX isn't terrible. Maybe I'll add it to start, and we can strip it back out if decided unnecessary.

@conneryn commented on GitHub (Jan 12, 2023): I'm interested in taking a stab at implementing this. I'm thinking an endpoint: `/.well-known/immich` with payload: ``` { "api": { "endpoint": "https://api.example.com/" } } ``` Re: auto-adding `https` if missing. This is easy enough implement, but I wonder if it adds too many special cases? And the UI already informs the user that http/s is required, so the UX isn't terrible. Maybe I'll add it to start, and we can strip it back out if decided unnecessary.
OVERLORD commented 2026-02-04 19:10:50 +03:00
Author
Owner
Copy Link

@jrasm91 commented on GitHub (Jan 12, 2023):

Will this just be a static file? How will it be hosted?

@jrasm91 commented on GitHub (Jan 12, 2023): Will this just be a static file? How will it be hosted?
OVERLORD commented 2026-02-04 19:10:54 +03:00
Author
Owner
Copy Link

@conneryn commented on GitHub (Jan 12, 2023):

I think hosted as part of the web project makes the most sense, that way we can use an environment variable to control the value. If performance is a concern, sveltejs should be able to pre-render/cache the endpoint as a static (though, I'm a little new to svelte, so not 100% sure what the right incantations are, yet, but I'm pretty sure it's possible 😅).

I should have an initial PR for this shortly, to show what I'm thinking.

@conneryn commented on GitHub (Jan 12, 2023): I think hosted as part of the web project makes the most sense, that way we can use an environment variable to control the value. If performance is a concern, `sveltejs` should be able to pre-render/cache the endpoint as a static (though, I'm a little new to `svelte`, so not 100% sure what the right incantations are, yet, but I'm pretty sure it's possible 😅). I should have an initial PR for this shortly, to show what I'm thinking.
OVERLORD commented 2026-02-04 19:11:02 +03:00
Author
Owner
Copy Link

@jrasm91 commented on GitHub (Jan 12, 2023):

Sounds good to me. I was wondering if you couldn't get the hostname from the request and return a dynamic response. An env variable sounds good though.

@jrasm91 commented on GitHub (Jan 12, 2023): Sounds good to me. I was wondering if you couldn't get the hostname from the request and return a dynamic response. An env variable sounds good though.
OVERLORD commented 2026-02-04 19:11:09 +03:00
Author
Owner
Copy Link

@Mortein commented on GitHub (Jan 12, 2023):

Re: auto-adding https if missing. This is easy enough implement, but I wonder if it adds too many special cases? And the UI already informs the user that http/s is required, so the UX isn't terrible. Maybe I'll add it to start, and we can strip it back out if decided unnecessary.

The full URL (including the protocol and port if non-standard) in the .well-known file would be best (so "endpoint": "https://immich15.example.com:4443/api"), as it would allow discovery by anything, not just the mobile app (things like backup systems, other Immich servers, upload tools, or other crazy things not yet thought of).

Ideally, the user should need to enter only enough for the mobile app to identify the actual API endpoint URL. Assume HTTPS if the user doesn't include a protocol.

Entering:

  • immich15.example.com would try https://immich15.example.com/.well-known/immich and find nothing, as the API is on a non-standard HTTPS port
  • http://immich15.example.com would try http://immich15.example.com/.well-known/immich and find nothing, as the API is not running on HTTP port 80
  • immich15.example.com:4443 would try https://immich15.example.com:4443/.well-known/immich and find some JSON which includes the api.endpoint
  • https://immich15.example.com:4443/api would not look for /.well-known/immich as there's already a path. Instead it would directly find the API
    • immich15.example.com:4443/api would also work, as it would try https://immich15.example.com:4443/api

There will be a disconnect between the entered URL and the API endpoint URL, but that's okay, as the API could be on a completely different domain (maybe you enter immich.example.com and api.endpoint sends you to https://immich22.example.net:14333/cats/api). It makes more sense for the user to enter the friendly URL.

@Mortein commented on GitHub (Jan 12, 2023): > Re: auto-adding `https` if missing. This is easy enough implement, but I wonder if it adds too many special cases? And the UI already informs the user that http/s is required, so the UX isn't terrible. Maybe I'll add it to start, and we can strip it back out if decided unnecessary. The full URL (including the protocol and port if non-standard) in the .well-known file would be best (so `"endpoint": "https://immich15.example.com:4443/api"`), as it would allow discovery by anything, not just the mobile app (things like backup systems, other Immich servers, upload tools, or other crazy things not yet thought of). Ideally, the user should need to enter only enough for the mobile app to identify the actual API endpoint URL. Assume HTTPS if the user doesn't include a protocol. Entering: * `immich15.example.com` would try `https://immich15.example.com/.well-known/immich` and find nothing, as the API is on a non-standard HTTPS port * `http://immich15.example.com` would try `http://immich15.example.com/.well-known/immich` and find nothing, as the API is not running on HTTP port 80 * `immich15.example.com:4443` would try `https://immich15.example.com:4443/.well-known/immich` and find some JSON which includes the `api.endpoint` * `https://immich15.example.com:4443/api` would not look for `/.well-known/immich` as there's already a path. Instead it would directly find the API * `immich15.example.com:4443/api` would also work, as it would try `https://immich15.example.com:4443/api` There will be a disconnect between the entered URL and the API endpoint URL, but that's okay, as the API could be on a completely different domain (maybe you enter `immich.example.com` and `api.endpoint` sends you to `https://immich22.example.net:14333/cats/api`). It makes more sense for the user to enter the friendly URL.
OVERLORD commented 2026-02-04 19:11:23 +03:00
Author
Owner
Copy Link

@conneryn commented on GitHub (Jan 13, 2023):

Thanks @Mortein, the clear examples of each scenario is very helpful. I've update my PR to include the logic as described (See here).

However, I do wonder about the last example, where a path exists. Even if a path exists in the input, I could see an argument to still first check for a .well-known. I'm imagining a case where a deployment have the public immich web available at: https://example.com/immich, and an end-user could (understandably) enter that as the URL when signing in, but we would still want to resolve a proper API endpoint. Thoughts?

@conneryn commented on GitHub (Jan 13, 2023): Thanks @Mortein, the clear examples of each scenario is very helpful. I've update my PR to include the logic as described (See [here](https://github.com/immich-app/immich/pull/1308/commits/9dae5b8317cfc4255b90317af574471c170be56b#diff-8787d212fe93bfb266c89e70f1f6a922a9aa859747d2d7f0227763de90298299)). However, I do wonder about the last example, where a path exists. Even if a path exists in the input, I could see an argument to still first check for a `.well-known`. I'm imagining a case where a deployment have the public immich web available at: https://example.com/immich, and an end-user could (understandably) enter that as the URL when signing in, but we would still want to resolve a proper API endpoint. Thoughts?
OVERLORD commented 2026-02-04 19:11:32 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Jan 13, 2023):

Thanks @Mortein, the clear examples of each scenario is very helpful. I've update my PR to include the logic as described (See here).

However, I do wonder about the last example, where a path exists. Even if a path exists in the input, I could see an argument to still first check for a .well-known. I'm imagining a case where a deployment have the public immich web available at: https://example.com/immich, and an end-user could (understandably) enter that as the URL when signing in, but we would still want to resolve a proper API endpoint. Thoughts?

From historical information, if the user use /immich or equivalent configuration for proxy, it wouldn't work

@alextran1502 commented on GitHub (Jan 13, 2023): > Thanks @Mortein, the clear examples of each scenario is very helpful. I've update my PR to include the logic as described (See [here](https://github.com/immich-app/immich/pull/1308/commits/9dae5b8317cfc4255b90317af574471c170be56b#diff-8787d212fe93bfb266c89e70f1f6a922a9aa859747d2d7f0227763de90298299)). > > > > However, I do wonder about the last example, where a path exists. Even if a path exists in the input, I could see an argument to still first check for a `.well-known`. I'm imagining a case where a deployment have the public immich web available at: https://example.com/immich, and an end-user could (understandably) enter that as the URL when signing in, but we would still want to resolve a proper API endpoint. Thoughts? From historical information, if the user use /immich or equivalent configuration for proxy, it wouldn't work
OVERLORD commented 2026-02-04 19:11:39 +03:00
Author
Owner
Copy Link

@jrasm91 commented on GitHub (Jan 13, 2023):

(#516)

@jrasm91 commented on GitHub (Jan 13, 2023): (#516)
OVERLORD commented 2026-02-04 19:11:44 +03:00
Author
Owner
Copy Link

@Mortein commented on GitHub (Jan 13, 2023):

I think you're right @conneryn. Even though there can only be a single instance on a specific hostname for now (until #516), that doesn't mean it couldn't just check for .well-known anyway, even if there is a path...

So (continuing the immich15.example.com host from earlier), entering:

  • https://immich15.example.com:4443/BobsPhotos would look for https://immich15.example.com:4443/BobsPhotos/.well-known/immich and either find some JSON which includes the correct api.endpoint, or use the given URL as the API URL
@Mortein commented on GitHub (Jan 13, 2023): I think you're right @conneryn. Even though there can only be a single instance on a specific hostname for now (until #516), that doesn't mean it couldn't just check for `.well-known` anyway, even if there is a path... So (continuing the `immich15.example.com` host from earlier), entering: * `https://immich15.example.com:4443/BobsPhotos` would look for `https://immich15.example.com:4443/BobsPhotos/.well-known/immich` and either find some JSON which includes the correct `api.endpoint`, or use the given URL as the API URL
OVERLORD commented 2026-02-04 19:11:57 +03:00
Author
Owner
Copy Link

@jrasm91 commented on GitHub (Jan 13, 2023):

I'll just add add that this is how openid discovery works as well, so it would make it consistent to support prefixes.

@jrasm91 commented on GitHub (Jan 13, 2023): I'll just add add that this is how [openid discovery works](https://openid.net/specs/openid-connect-discovery-1_0.html#rfc.section.4) as well, so it would make it consistent to support prefixes.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
accessibility
changelog:enhancement
changelog:security
changelog:translation
cli
date-time
documentation
external-library
format
good first issue
needs-answer
nice to have
sharing
tech-debt
📱mobile
🖥️web
🗄️server
🧠machine-learning
No Label good first issue
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#261
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?