Hi Michael,
On 06/01/2025 17:28, Michael Tremer wrote:
Hello Adolf,
I assume this might not fully fix the problem since we don’t know for certain if the uploaded file is a JPEG file.
I am sorry, I had intended to put something about that into the commit but I forgot to do it.
I had various image files which I could check the type of and I found a jpg, a png and a tiff image file.
I uploaded each of these in turn and the same image/jpeg content type successfully displayed the uploaded image onto the browser screen.
I believe this is why have chosen something very generic instead of a specific image type. I assume that we would have to run something to check the correct MIME type of the file before we can send anything.
Of course it might be that how I have done it works for now for any (most/some) image files but it could also change in the future.
https://metacpan.org/release/FITZNER/File-LibMagic-0.96/view/LibMagic.pm
This could do the job.
I can have a look at that link and modify the code if you would prefer that.
In the wiki we explicitly say jpg or png only, although as I said I was able to successfully upload a tiff image file and it was displayed.
We can maybe discuss further in the conf call to finalise on what I should do.
Regards, Adolf.
-Michael
On 6 Jan 2025, at 16:21, Adolf Belka adolf.belka@ipfire.org wrote:
- Something changed in some package in CU188 that means that the existing method of printing the content type to the browser no longer worked.
- I tested it in some stand alone code and even if using text/txt for the content-type print statement the File::Copy::copy then resulted in an Internal Server Error with the same message as with the image file which was "malformed header from script 'logo.cgi': Bad header:".
- I tested it with text, html, image and application. In all cases the error message about a bad header was provided.
- Did some searching and found an alternative way to explicitly print the header info which is what I have used in this patch change.
- With this approach, in the stand alone code, I was able to get an image, html code or text shown in the browser correctly and without any error message.
- I then used this new method in the logo.cgi code as submitted here and tested the change in my vm testbed and the image was shown in the captive portal correctly.
- So this change fixes the problem with the logo not being shown but I have been unable to identify what changed to stop the method that worked prior to CU188 from working any more.
Fixes: Bug13795 Tested-by: Adolf Belka adolf.belka@ipfire.org Signed-off-by: Adolf Belka adolf.belka@ipfire.org
html/cgi-bin/captive/logo.cgi | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/html/cgi-bin/captive/logo.cgi b/html/cgi-bin/captive/logo.cgi index 8f292b171..09fe784b8 100644 --- a/html/cgi-bin/captive/logo.cgi +++ b/html/cgi-bin/captive/logo.cgi @@ -2,9 +2,9 @@ ############################################################################### # # # IPFire.org - A linux based firewall # -# Copyright (C) 2016 Alexander Marx alexander.marx@ipfire.org # +# Copyright (C) 2016-2024 IPFire Team info@ipfire.org # # # -# This program is free software you can redistribute it and/or modify # +# This program is free software: you can redistribute it and/or modify # # it under the terms of the GNU General Public License as published by # # the Free Software Foundation, either version 3 of the License, or # # (at your option) any later version. # @@ -29,6 +29,7 @@ use File::Copy;
require '/var/ipfire/general-functions.pl';
+my $q = new CGI; my $logo = "${General::swroot}/captive/logo.dat";
# Send 404 if logo was not uploaded and exit @@ -37,8 +38,8 @@ if (!-e $logo) { exit(0); }
-print "Content-Type: application/octet-stream\n\n";
# Send image data +print $q->header(-type=>"image/jpeg"); +binmode STDOUT; File::Copy::copy $logo, *STDOUT; exit(0); -- 2.47.1