Problem with avatars and attachments in IE after installing 2.0.6

Started by WimB, October 27, 2013, 03:25:04 PM

Previous topic - Next topic

WimB

This morning we installed patch 2.0.6 to our forum (update from 2.0.5). Our members which are using IE can no longer see some of the avatars and attachments. They work perfectly in Firefox, Safari,....

Anyone any idea what the cause might be? (something with the programming which IE doesn't digest very well it would seem ;))

Arantor

Well... the 2.0.6 patch did not change how avatars and attachments are served. It *did* change how avatars get *saved* but that only kicks in when someone actually updates their avatar.

What else changed for your users?
No good deed goes unpunished / All helpful urges should be circumvented

I have something to say: it's better to burn out than to fade away. There can be only one.

WimB

The only thing we changed was update the patch and change the time from summertime to wintertime.

For the rest no changes were made and I've heard no other complaints, when the IE users renew their avatar, it is visible again in IE, but that's not possible for the attachments.

Arantor

I don't know what to tell you.

Here's what I know, for certain (mostly because I'm the one who wrote the patch)...

1) The patch did not touch Display.php, which is where action=dlattach is located (and action=dlattach is what serves avatars and attachments)

2) The only change that does come up in index.php?action=dlattach is the change to index.php where extra headers were added. If the headers were damaging the process, it would break new uploads too.

As a test, though, you could try commenting out this line from index.php:
header('X-Content-Type-Options: nosniff');

But as I understand it, both Facebook and Twitter use this and they haven't had any problems.

Is it all IE users on your site? Is it all files or just some of them?
No good deed goes unpunished / All helpful urges should be circumvented

I have something to say: it's better to burn out than to fade away. There can be only one.

WimB

Quote from: Arantor on October 27, 2013, 03:50:57 PM
I don't know what to tell you.

Here's what I know, for certain (mostly because I'm the one who wrote the patch)...

1) The patch did not touch Display.php, which is where action=dlattach is located (and action=dlattach is what serves avatars and attachments)

2) The only change that does come up in index.php?action=dlattach is the change to index.php where extra headers were added. If the headers were damaging the process, it would break new uploads too.

As a test, though, you could try commenting out this line from index.php:
header('X-Content-Type-Options: nosniff');

But as I understand it, both Facebook and Twitter use this and they haven't had any problems.

Is it all IE users on your site? Is it all files or just some of them?

Thanks Arantor, will try the commenting out.

All IE users have the problem (all versions of IE) and it's just some of the files, but it's not related to the format, they are all jpg but the pics that are still visible are jpg too.

WimB

commenting that out didn't change anything either....Thank you very much for helping Arantor!

Arantor

Is there anything the files have in common?

Do they have funny characters in the names (when they don't work properly)?
No good deed goes unpunished / All helpful urges should be circumvented

I have something to say: it's better to burn out than to fade away. There can be only one.

WimB

Quote from: Arantor on October 27, 2013, 04:05:24 PM
Is there anything the files have in common?

Do they have funny characters in the names (when they don't work properly)?

Nothing in common....no funny characters in the names.
Just noticed that when I rightclick on the black x where the attachment should be and select "open link in a new tab", it shows the attachment correctly.

Arantor

Ah, so thumbnail generation failed. But my changes didn't touch Subs-Graphics where that occurs.
No good deed goes unpunished / All helpful urges should be circumvented

I have something to say: it's better to burn out than to fade away. There can be only one.

WimB

So, something we changed must have affected Subs-Graphics in a way that only IE responds badly to it.....

Arantor

No good deed goes unpunished / All helpful urges should be circumvented

I have something to say: it's better to burn out than to fade away. There can be only one.

WimB


mashby

Some avatars and attachments? Mind providing a link to where an avatar isn't displaying properly in IE? And one with attachments, too?
Always be a little kinder than necessary.
- James M. Barrie

WimB

Quote from: monster mashby on October 27, 2013, 04:28:08 PM
Some avatars and attachments? Mind providing a link to where an avatar isn't displaying properly in IE? And one with attachments, too?

Here you go monster M: http : //www.vrvforum.be/forum/index.php?topic=1209.0 [nofollow]

lurkalot

Quote from: Arantor on October 27, 2013, 04:24:23 PM
Well, it wasn't 2.0.6...

Arantor.  Well I'm glad I read this thread.  As you know I uploaded a fresh set of files to my site and now I'm missing some of my users avatars too. they also show in Firefox and Chrome, but not in IE10 as they did before the upgrade.  ???

Arantor

OK, so let's try something really crazy.

Comment out this line from index.php.
header('X-XSS-Protection: 1; mode=block');
No good deed goes unpunished / All helpful urges should be circumvented

I have something to say: it's better to burn out than to fade away. There can be only one.

lurkalot

Quote from: Arantor on October 27, 2013, 06:00:26 PM
OK, so let's try something really crazy.

Comment out this line from index.php.
header('X-XSS-Protection: 1; mode=block');

Tried it, but unfortunately it made no difference.  :(

Arantor

I didn't really expect it to, but it was one option that might have done; IE is a bit crazy when it comes to those headers (even though it was IE that introduced them originally!)
No good deed goes unpunished / All helpful urges should be circumvented

I have something to say: it's better to burn out than to fade away. There can be only one.

lurkalot

Strange how its just blocking some and not all off the uploaded avatars.  If I go to Admin > Forum > Attachments and avatars > Browse files > Avatars, the missing ones are there, and I can view them.

Some Of my members have since uploaded them again (including me).

WimB

Really strange.... nothing seems to have changed in Subs-Graphics either  :o

Arantor

No good deed goes unpunished / All helpful urges should be circumvented

I have something to say: it's better to burn out than to fade away. There can be only one.

watchhorse

I have the same problem. ???
Also after update.
Wij zoeken diergerelateerde fora ter overname.
Pb gerust als je geen tijd of zin meer hebt om uw forum te onderhouden.

Arantor

And yet as shown the patch doesn't TOUCH the avatars or attachments code...

You could try commenting out the three headers in index.php that were added but they didn't break it for me when I tested it...
No good deed goes unpunished / All helpful urges should be circumvented

I have something to say: it's better to burn out than to fade away. There can be only one.

lurkalot

Quote from: Arantor on October 28, 2013, 10:34:53 AM
And yet as shown the patch doesn't TOUCH the avatars or attachments code...

You could try commenting out the three headers in index.php that were added but they didn't break it for me when I tested it...

Arantor, did just that and I can now confirm the Avatars are working again. ;)

Arantor

And commenting out the last two didn't fix it before?

The Frame-Options header should NOT be doing that. Proof, if any were needed, that IE still lags behind in supporting something that's been around for years.


Still, if you'd rather have less security, that's entirely up to you.
No good deed goes unpunished / All helpful urges should be circumvented

I have something to say: it's better to burn out than to fade away. There can be only one.

lurkalot

Quote from: Arantor on October 28, 2013, 11:28:50 AM

And commenting out the last two didn't fix it before?


I didn't try the last two before, just this line that you told us to try header('X-XSS-Protection: 1; mode=block');

Which didn't make any difference for me.  Then I tried all three headers as you just suggested and the avatars work again.


header('X-Frame-Options: SAMEORIGIN');
header('X-XSS-Protection: 1; mode=block');
header('X-Content-Type-Options: nosniff');

Arantor

Um, if you read the thread, I suggested removing the last two at separate points in the thread.

So it's down to the Frame-Options header, which is fantastic because that's the most useful of the headers to add. Interestingly, Facebook and Twitter use the same header - so it's down to IE as to why it doesn't work.
No good deed goes unpunished / All helpful urges should be circumvented

I have something to say: it's better to burn out than to fade away. There can be only one.

lurkalot

Quote from: Arantor on October 28, 2013, 11:43:54 AM
Um, if you read the thread, I suggested removing the last two at separate points in the thread.

So it's down to the Frame-Options header, which is fantastic because that's the most useful of the headers to add. Interestingly, Facebook and Twitter use the same header - so it's down to IE as to why it doesn't work.

Sorry, I should have read back the whole thread.  :-[

But after a bit of testing, it's actually this line alone that's stopping the avatars showing header('X-Content-Type-Options: nosniff');  Not the Frame options one.

Arantor

That's even more hilarious... that's a feature IE themselves invented first!

Makes me wonder why it's broken anything else.
No good deed goes unpunished / All helpful urges should be circumvented

I have something to say: it's better to burn out than to fade away. There can be only one.

mashby

Hmm...looking at the differences between here and the OP's site.
OP's avatar:
http://www.vrvforum.be/forum/index.php?action=dlattach;attach=27229;type=avatar
in IMG tag:

Arantor's avatar:
http://avatars.simplemachinesweb.com/smf/avatar_318771_1380747238.jpg
in IMG tag:


I'm guessing here is different in terms of avatar paths. Here looks more "normal" in terms of an img src, but the other way seems to work OK too, just not always in IE.

In IE10, the img referenced from the IMG tag indeed doesn't show up. :)
Always be a little kinder than necessary.
- James M. Barrie

Arantor

That's because here has avatars set to an avatar directory because it makes things *crazy* faster. That wouldn't fix attachments though.
No good deed goes unpunished / All helpful urges should be circumvented

I have something to say: it's better to burn out than to fade away. There can be only one.

margarett

Quote from: monster mashby on October 28, 2013, 12:42:16 PM
In IE10, the img referenced from the IMG tag indeed doesn't show up. :)
In IE8 also doesn't show up. IE8 is damn old, but it's strange the the issue crosses so different versions...
Se forem conduzir, não bebam. Se forem beber... CHAMEM-ME!!!! :D

QuoteOver 90% of all computer problems can be traced back to the interface between the keyboard and the chair

Arantor

Especially for a header introduced in IE8 for 'better security'.

Though I get the feeling it should really be issuing proper MIME type headers and nosniff confuses it.
No good deed goes unpunished / All helpful urges should be circumvented

I have something to say: it's better to burn out than to fade away. There can be only one.

WimB

Thanks to all (and especially to Arantor)  :)

it works again, after commenting out all three, only commenting out header('X-Content-Type-Options: nosniff'); didn't work over here. Will have to do with less security, I guess....IE (sigh)  >:(

margarett

Well, I guess you can minimize the damage by putting out that lines only if browser is IE by looking at _SERVER['HTTP_USER_AGENT']
?

Se forem conduzir, não bebam. Se forem beber... CHAMEM-ME!!!! :D

QuoteOver 90% of all computer problems can be traced back to the interface between the keyboard and the chair

GrogHead

Quote from: Arantor on October 28, 2013, 12:26:40 PM
That's even more hilarious... that's a feature IE themselves invented first!

Makes me wonder why it's broken anything else.

This may need to go in a new thread, but it looks like you may be asking if IE broke anything else.

We just upgraded to 2.0.6 today. This morning I had a user access our forum with no problem using IE 10. This afternoon (after upgrading to 2.0.6) he tells me he cannot access our forums. He installed Chrome and has no problems.

He tried to access on two different machines, both running IE. He has tried deleting cookies and internet files then rebooting with no change. He gets the following error when he tries to hit us:

QuoteAn Error Has Occurred!


Session verification failed. Please try logging out and back in again, and then try again.

Any suggestions would be appreciated.

Arantor

Well, I'm not so much asking whether it did, all evidence is that it did. I'm asking *why*, because the changes that were made were made to Microsoft's *own* specification; Microsoft added that header in IE and adoption is growing.

But yours is the first example of it actually failing something else. You can try commenting out the headers as suggested and see if that makes a difference.
No good deed goes unpunished / All helpful urges should be circumvented

I have something to say: it's better to burn out than to fade away. There can be only one.

GrogHead

Quote from: Arantor on October 28, 2013, 07:36:47 PM
Well, I'm not so much asking whether it did, all evidence is that it did. I'm asking *why*, because the changes that were made were made to Microsoft's *own* specification; Microsoft added that header in IE and adoption is growing.

But yours is the first example of it actually failing something else. You can try commenting out the headers as suggested and see if that makes a difference.

Thanks. I think we're just going to encourage folks to use a different browser.

In any case, if you need anything from me were you to decide to try and debug MS's problem, feel free to contact me  8)

lurkalot

@ Arantor.  Just curious, if these headers are causing certain Avatars not to display, then why do they display fine after a member re=uploads their avatar.  Like I said earlier, it wasn't all the uploaded avatars just a few random ones.  That included my own one, I re-uploaded the same one and it shows fine, and a handful of members done the same and they were ok too.  Any ideas?

Arantor

No good deed goes unpunished / All helpful urges should be circumvented

I have something to say: it's better to burn out than to fade away. There can be only one.

GL700Wing

Quote from: Arantor on November 01, 2013, 12:21:20 AM
I got no idea why they're failing in the first place ;)
My forum users have also experienced the same issues with IE not always displaying images since the upgrade to 2.0.6 and commenting out the following line in index.php fixed the issue in a few posts I checked:
header('X-Content-Type-Options: nosniff');

After reading this thread (and 2.0.6 upgrade - simple portal block issue) I did a bit of Googling and found the following: IE9 and IE10 does not display CAPTCHA image sometimes and JIRA will not display images with the wrong MIME type in IE due to nosniff header

Based on the information in the these two posts about the issue relating to the incorrect MIME type I then checked the value of 'mime_type' in the 'smf_attachment's table for the images that would not display with 'nosniff' enabled and discovered that it was empty.  As the images were 'jpg' images I updated the 'mime_type' field with the value 'image/jpeg' (and re-enabled 'nosniff' in index.php) and after refreshing the page the images displayed!

I then ran the following SQL commands against my database (after making a backup first!) for the different image types and IE is now behaving itself!

UPDATE `smf_attachments` SET `mime_type` = 'image/bmp' WHERE `fileext` = 'bmp' AND `mime_type` = '';
UPDATE `smf_attachments` SET `mime_type` = 'image/gif' WHERE `fileext` = 'gif' AND `mime_type` = '';
UPDATE `smf_attachments` SET `mime_type` = 'image/jpeg' WHERE `fileext` = 'jpg' AND `mime_type` = '';
UPDATE `smf_attachments` SET `mime_type` = 'image/png' WHERE `fileext` = 'png' AND `mime_type` = '';
Life doesn't have to be perfect to be wonderful ...

Arantor

Ahhhh, that makes sense, though that should primarily only affect 1.1.x (which doesn't store the MIME type) and early 2.0 (which also didn't), but that does mean it is something the upgrader should fix.

As far as the CAPTCHA goes, it should always be issued with the correct header?
No good deed goes unpunished / All helpful urges should be circumvented

I have something to say: it's better to burn out than to fade away. There can be only one.

GL700Wing

Quote from: Arantor on November 06, 2013, 08:08:03 AM
Ahhhh, that makes sense, though that should primarily only affect 1.1.x (which doesn't store the MIME type) and early 2.0 (which also didn't), ...
I only upgraded from 1.1.18 to 2.0.4 a few months ago and I noticed when I checked the 1.1.18 database a short time ago that the 'mime_type' field wasn't in the 'smf_attachments' table - I figure you'd know when it was introduced to 2.0.  Only recent attachments had the 'mime_type' field populated in the 'smf_attachments' table in my 2.0.6 database.

Quote from: Arantor on November 06, 2013, 08:08:03 AM
... but that does mean it is something the upgrader should fix.
Does that mean I should also set the 'mime_type' for all attachment types (eg, pdf, txt, zip. etc)?

Quote from: Arantor on November 06, 2013, 08:08:03 AM
As far as the CAPTCHA goes, it should always be issued with the correct header?
I don't know - I don't use CAPTCHA.  I only used that link as a reference because it helped me understand the cause of the issue.
Life doesn't have to be perfect to be wonderful ...

Arantor

QuoteDoes that mean I should also set the 'mime_type' for all attachment types (eg, pdf, txt, zip. etc)?

It really matters for images, but isn't so important for the non image types. I forget whether SMF itself even bothers for those.
No good deed goes unpunished / All helpful urges should be circumvented

I have something to say: it's better to burn out than to fade away. There can be only one.

GL700Wing

Quote from: Arantor on November 06, 2013, 08:46:10 AM
QuoteDoes that mean I should also set the 'mime_type' for all attachment types (eg, pdf, txt, zip. etc)?

It really matters for images, but isn't so important for the non image types. I forget whether SMF itself even bothers for those.
Thanks for the info - I won't worry about updating the MIME type for non-image file types at this time.
Life doesn't have to be perfect to be wonderful ...

Scott Hamilton

Quote from: GL700Wing on November 06, 2013, 07:34:38 AM
Quote from: Arantor on November 01, 2013, 12:21:20 AM
I got no idea why they're failing in the first place ;)
My forum users have also experienced the same issues with IE not always displaying images since the upgrade to 2.0.6 and commenting out the following line in index.php fixed the issue in a few posts I checked:
header('X-Content-Type-Options: nosniff');

After reading this thread (and 2.0.6 upgrade - simple portal block issue) I did a bit of Googling and found the following: IE9 and IE10 does not display CAPTCHA image sometimes and JIRA will not display images with the wrong MIME type in IE due to nosniff header

Based on the information in the these two posts about the issue relating to the incorrect MIME type I then checked the value of 'mime_type' in the 'smf_attachment's table for the images that would not display with 'nosniff' enabled and discovered that it was empty.  As the images were 'jpg' images I updated the 'mime_type' field with the value 'image/jpeg' (and re-enabled 'nosniff' in index.php) and after refreshing the page the images displayed!

I then ran the following SQL commands against my database (after making a backup first!) for the different image types and IE is now behaving itself!

UPDATE `smf_attachments` SET `mime_type` = 'image/bmp' WHERE `fileext` = 'bmp' AND `mime_type` = '';
UPDATE `smf_attachments` SET `mime_type` = 'image/gif' WHERE `fileext` = 'gif' AND `mime_type` = '';
UPDATE `smf_attachments` SET `mime_type` = 'image/jpeg' WHERE `fileext` = 'jpg' AND `mime_type` = '';
UPDATE `smf_attachments` SET `mime_type` = 'image/png' WHERE `fileext` = 'png' AND `mime_type` = '';

Wow, GL700Wing- this worked great! I ran you query's on my db and everything is working correctly again. Thank you!

Been running the software since the YaBBSE days.. Had this issue for a while now and could not figure it out, you are the man.

Scott
Been with SMF since the YabbSE Days...
http://www.fordpinto.com

Advertisement: