Thanks for fixing the previous bug setting a url for the logo.
The previous url I was using worked. This url structure does not.
Change it and its throwing an error using a url structure like this -
URL - https://subdomain.domainname.com/images/Microsoft1.png - example. This is an active url - changed the values since I didnt want to post my actual url but provides a view of the structure which isn't anything complicated.
Originally created by @jiriteach on GitHub (Jan 25, 2026).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/2325
Originally assigned to: @miloschwartz on GitHub.
### Describe the Bug
Thanks for fixing the previous bug setting a url for the logo.
The previous url I was using worked. This url structure does not.
Change it and its throwing an error using a url structure like this -
URL - https://subdomain.domainname.com/images/Microsoft1.png - example. This is an active url - changed the values since I didnt want to post my actual url but provides a view of the structure which isn't anything complicated.
Error -
`Too big: expected string to have <=0 characters`
### Environment
- Pangolin Version: 1.15.1
- Traefik Version: 3.6.7
### To Reproduce
Enter logo url in the form of - URL - https://subdomain.domainname.com/images/Microsoft1.png - example. This url wont work since I didnt want to post my actual url.
### Expected Behavior
For the logo url to be set.
GiteaMirror
added the bug label 2026-04-20 08:31:00 -05:00
@oschwartz10612 commented on GitHub (Jan 26, 2026):
We are working on a fix for the next patch. Make sure the url you enter
is a valid URL to a hosted image where the content type is an image.
<!-- gh-comment-id:3801927685 -->
@oschwartz10612 commented on GitHub (Jan 26, 2026):
We are working on a fix for the next patch. Make sure the url you enter
is a valid URL to a hosted image where the content type is an image.
We are working on a fix for the next patch. Make sure the url you enter
is a valid URL to a hosted image where the content type is an image.
Thanks. In my case - its just an image hosted on Cloudlare r2 so s3 storage with publicly enabled access.
<!-- gh-comment-id:3802473234 -->
@jiriteach commented on GitHub (Jan 27, 2026):
> We are working on a fix for the next patch. Make sure the url you enter
> is a valid URL to a hosted image where the content type is an image.
Thanks. In my case - its just an image hosted on Cloudlare r2 so s3 storage with publicly enabled access.
Cloudflare/S3 isn't properly setting the Content-Type header for your image
Zod fails the url validation, falls back to the empty string case, fails the empty string case, and then displays the empty string error
I think the misleading error could be fixed by doing .superRefine and then explicitly setting the fallback order instead of dealing with Zod's default fallback order here:
logoUrl: z.string().superRefine(async(val,ctx)=>{// empty string case from before
if(val.length===0){return;}// check for url
consturlResult=z.string().url().safeParse(val);if(!urlResult.success){ctx.addIssue({code: z.ZodIssueCode.custom,message:"Must be a valid URL"});return;}// validate image
try{...if(failed){ctx.addIssue({code: z.ZodIssueCode.custom,message:"Invalid logo URL, must be served as an image"});}else{return;}}catch(error){ctx.addIssue({code: z.ZodIssueCode.custom,message:"Failed to retrieve image"});}})
Would also help specify "valid image URL" means it's served back with a Content-Type header.
<!-- gh-comment-id:3832304765 -->
@gyoge0 commented on GitHub (Feb 1, 2026):
[Relevant snippet](https://github.com/fosrl/pangolin/blob/b0566d3c6fc0e2a993c8606acc128a68c4e27247/src/components/AuthPageBrandingForm.tsx#L45-L65)
I think the two things going on here are:
1. Cloudflare/S3 isn't properly setting the `Content-Type` header for your image
2. Zod fails the url validation, falls back to the empty string case, fails the empty string case, and then displays the empty string error
I think the misleading error could be fixed by doing `.superRefine` and then explicitly setting the fallback order instead of dealing with Zod's default fallback order here:
```ts
logoUrl: z.string().superRefine(async (val, ctx) => {
// empty string case from before
if (val.length === 0) {
return;
}
// check for url
const urlResult = z.string().url().safeParse(val);
if (!urlResult.success) {
ctx.addIssue({
code: z.ZodIssueCode.custom,
message: "Must be a valid URL"
});
return;
}
// validate image
try {
...
if (failed) {
ctx.addIssue({
code: z.ZodIssueCode.custom,
message: "Invalid logo URL, must be served as an image"
});
} else {
return;
}
} catch (error) {
ctx.addIssue({
code: z.ZodIssueCode.custom,
message: "Failed to retrieve image"
});
}
})
```
Would also help specify "valid image URL" means it's served back with a `Content-Type` header.
@bobbleheadhobo commented on GitHub (Feb 5, 2026):
I am having the same issue. I have my logo hosted on Imgur, and I get the same error. Although I think something else is going on, like gyoge0 mentioned, because if I paste in the image address of the logo from the pangolin website, it works just fine. Any suggestions on where I should host my logo to get it to work?
<!-- gh-comment-id:3851274344 -->
@bobbleheadhobo commented on GitHub (Feb 5, 2026):
I am having the same issue. I have my logo hosted on Imgur, and I get the same error. Although I think something else is going on, like gyoge0 mentioned, because if I paste in the image address of the logo from the pangolin website, it works just fine. Any suggestions on where I should host my logo to get it to work?
@oschwartz10612 commented on GitHub (Feb 25, 2026):
I think this was resolved in 1.15.3. Please reopen if this was not the case.
<!-- gh-comment-id:3961179554 -->
@oschwartz10612 commented on GitHub (Feb 25, 2026):
I think this was resolved in 1.15.3. Please reopen if this was not the case.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @jiriteach on GitHub (Jan 25, 2026).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/2325
Originally assigned to: @miloschwartz on GitHub.
Describe the Bug
Thanks for fixing the previous bug setting a url for the logo.
The previous url I was using worked. This url structure does not.
Change it and its throwing an error using a url structure like this -
URL - https://subdomain.domainname.com/images/Microsoft1.png - example. This is an active url - changed the values since I didnt want to post my actual url but provides a view of the structure which isn't anything complicated.
Error -
Too big: expected string to have <=0 charactersEnvironment
To Reproduce
Enter logo url in the form of - URL - https://subdomain.domainname.com/images/Microsoft1.png - example. This url wont work since I didnt want to post my actual url.
Expected Behavior
For the logo url to be set.
@jiriteach commented on GitHub (Jan 25, 2026):
@JustMePawel commented on GitHub (Jan 26, 2026):
I do have the same issue..
@oschwartz10612 commented on GitHub (Jan 26, 2026):
We are working on a fix for the next patch. Make sure the url you enter
is a valid URL to a hosted image where the content type is an image.
@jiriteach commented on GitHub (Jan 27, 2026):
Thanks. In my case - its just an image hosted on Cloudlare r2 so s3 storage with publicly enabled access.
@gyoge0 commented on GitHub (Feb 1, 2026):
Relevant snippet
I think the two things going on here are:
Content-Typeheader for your imageI think the misleading error could be fixed by doing
.superRefineand then explicitly setting the fallback order instead of dealing with Zod's default fallback order here:Would also help specify "valid image URL" means it's served back with a
Content-Typeheader.@bobbleheadhobo commented on GitHub (Feb 5, 2026):
I am having the same issue. I have my logo hosted on Imgur, and I get the same error. Although I think something else is going on, like gyoge0 mentioned, because if I paste in the image address of the logo from the pangolin website, it works just fine. Any suggestions on where I should host my logo to get it to work?
@oschwartz10612 commented on GitHub (Feb 25, 2026):
I think this was resolved in 1.15.3. Please reopen if this was not the case.