Closed Bug 500047 Opened 15 years ago Closed 15 years ago

SUMO should not be loading images from personal hosting servers

Categories

(support.mozilla.org :: General, defect)

Product:
support.mozilla.org
Component:
General
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: Dolske, Assigned: zzxc)

References

(
URL
)

Details

(Whiteboard: sumo_only) 

At least on http://support.mozilla.com/en-US/kb/How+to+contribute, there are a number of images being loaded from external sites. EG:

http://ilias.ca/sumo/foxkehmail.png
http://zzxc.net/1x1.png

These really, really shouldn't be on an external site.
This is caused by and probably a dupe of https://bugzilla.mozilla.org/show_bug.cgi?id=493276 ... fixing that would be awesome.  Failing that somewhere internal that we can host images without having to file IT bugs every time would also work as a workaround.
Depends on: 493276
No longer depends on: 493276
Not really. In the absence of a fix for 493276, content should reside on some other MoCo server.
Target Milestone: --- → 1.3
A while back, I remember zzxc mentioning using videos.m.o as a workaround for this. Is that preferred over using our own domains?
The preferred solution is to fix bug 493276.  Reed offered to put those images somewhere on our infrastructure until that happens.
What's the current status of this bug?
It's scheduled for 1.3 (along with bug 493276).  Reed, can you work with Chris re: comment #4?
Reed, right now it looks like bug 493276 is fixed as a result of a sumo 1.2.1 bug (bug 485665). It looks fixed on support-stage anyway. If sumo 1.2.1 pushes this week, we should be able to move the images to support.mozilla.com, and close this bug this week as well.
(In reply to comment #7)
> Reed, right now it looks like bug 493276 is fixed as a result of a sumo 1.2.1
> bug (bug 485665). It looks fixed on support-stage anyway. If sumo 1.2.1 pushes
> this week, we should be able to move the images to support.mozilla.com, and
> close this bug this week as well.

Sounds good. Let me know if I can help.
Bug 493276 is fixed on prod. I can take care of locating the links to remote images and hosting them on support.mozilla.com.
Assignee: nobody → bmo2008
English pages are done.
All remote images in articles are now hosted on support.mozilla.com.

zzxc, there's some stuff (not images) on https://support.mozilla.com/en-US/kb/Support%20Firefox%20Day and https://support.mozilla.com/en-US/kb/Live%20Chat%20troubleshooting%20guide that are hosted on zzxc.net.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
I think this needs to stay open until all the personal server stuff is removed. But thanks for getting the images moved!

That second link is sending usernames and email addresses to a CGI script on zzxc.net. (?!)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
As an unrelated note, it would be good if the video on that first link didn't restart itself after the user pauses it, and loop infinitely. :)
Reassigning to Matthew for the zzxc.net stuff.
Assignee: bmo2008 → bugs
(In reply to comment #12)
Yeah, that was bad but we didn't have much choice at the time (I can't access files on production -- sigh) and we decided to get it up very last minute so we needed a way that didn't touch the codebase.  Otherwise I'd basically be constantly pinging IT to check how many user signups we had and to send out reminder emails.

I'll take that down now that SFD is over.

Ditto the video... we had issues with streaming so zzxc hacked something together on his server to constantly refresh the iframe.  It's not a good solution but the video tag is really not at a good enough state for streaming we found out somewhat late.
Assignee: bugs → bmo2008
Assignee: bmo2008 → bugs
The files being loaded on Live+Chat+troubleshooting+guide are for a screencast I added before we had screencast support.  I'll transfer this screencast to SUMO, now that we have support for it.

Everything on Support+Firefox+Day was put up at the last minute for the event, so hosting on an external server was the only option we had.  (The video loops endlessly due to a javascript hack I made to prevent the live video stream from cutting out)
Guys, I really want to stress that I know your goals were solid and well-intentioned., but this type of thing is simply not appropriate.  We simply cannot send user data from production websites to personal servers just because it's faster/more convenient to do it that way.  It looks _extremely_ bad on the surface, and even knowing the details I'm really uncomfortable that we did things that way.  (To an unknowing observer, between the script and the 1x1 image, this sure would have looked like some guy named zzxc hacked SUMO and is tracking users and harvesting their user data.  That's pretty much what happened anyway, except you happen to work for us...)

As I guess a postmortem question: what do you guys need from IT/Webdev so we never ever go down this path again?  Ability to directly touch things in production is almost certainly not going to happen, everything is in version control for a reason.  Now, the ability to push reviewed changes to SVN and request a push to production by IT seems entirely viable, if Laura concurs...
I agree with what Mike said - we (IT) do a lot of last minute work and would have been able to handle this one too.
I removed the content being loaded from my server on the "Support Firefox Day" and "Live Chat troubleshooting guide" pages.  The live chat screencast is now hosted directly on SUMO, and the SFD static video is now embedded directly without the live stream hack.  I also fixed one remaining translation of "How to Contribute" that was referencing my server: http://support.mozilla.com/cs/kb/Jak+přispět?bl=n .

The 1x1.png image was already moved on-site for the en-US "How to contribute" page, so it's no longer being retrieved from my server.  We use this transparent image to create a fixed-pixel layout using TikiWiki markup, so that we can avoid manual HTML.

The registration script that was hosted on my server was collecting usernames of community members who were interested in attending Support Firefox Day.  We made a last minute decision to use a script on an external server when we realized that the TikiWiki tracker feature was not working.  I removed the <form> that was sending data here from the "Support Firefox Day" page, and we should definitely make every effort to avoid sending any data offsite in the future.

The only remaining off-site content I can find is the embedded Mibbit on "Support Firefox Day", so I'm marking this bug as fixed.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
(In reply to comment #17)

In my ideal world, I'd hope for:

1) A solid live open video streaming solution.  We thought it'd be good to showcase the open technology and do the first real well-advertised open video streaming event with screencasts.  That video was non-responsive for many of our users and needed constant refreshing was discovered about 30 minutes before the event.  (As far as 1 hour before the event, the page was just loading off videos.mozilla.org).  This was mostly my fault for not doing more testing on poorer connections but now that we know it's a problem, how do we address it (and who addresses it) for the next event?  

2) Some way to implement one-off features that need data we can access.  In this case, a sign-up system that wasn't going to be used on any other page. 

3) IT support during live events.  I hadn't realized how hard it was to put together a live event without someone else handling the servers and technology and monitoring the event.  I'll notify IT in advance of an event next time and so when things go wrong (like Mibbit going down or the video acting up) I can stay focused on content.
(In reply to comment #20)
> (In reply to comment #17)
> 
> In my ideal world, I'd hope for:
> 
> 1) A solid live open video streaming solution.  We thought it'd be good to
> showcase the open technology and do the first real well-advertised open video
> streaming event with screencasts.  That video was non-responsive for many of
> our users and needed constant refreshing was discovered about 30 minutes before
> the event.  (As far as 1 hour before the event, the page was just loading off
> videos.mozilla.org).  This was mostly my fault for not doing more testing on
> poorer connections but now that we know it's a problem, how do we address it
> (and who addresses it) for the next event?  
> 
> 2) Some way to implement one-off features that need data we can access.  In
> this case, a sign-up system that wasn't going to be used on any other page. 
> 
> 3) IT support during live events.  I hadn't realized how hard it was to put
> together a live event without someone else handling the servers and technology
> and monitoring the event.  I'll notify IT in advance of an event next time and
> so when things go wrong (like Mibbit going down or the video acting up) I can
> stay focused on content.

All of these are achievable when planned in advance.

1.  I'm not clear on what happened here.  You're saying it was faster to serve this from a personal server than from video.mozilla.org?  I'm also not clear when this became apparent.  We should work with IT to load test a solution.

2.  For this, file a bug as soon as you know we have a requirement, include the deadline of when it has to be done.  Then it can be appropriately scheduled for the release beforehand.  As you know we do a general release about every 3 weeks, but we do do special mini pushes for things that have a shorter deadline (e.g. Kampyle)  

3. Sounds like a good idea.  When planning the next SFD (or whatever) it would be good to come up with a list of requirements and circulate it to Webdev and IT for feedback and planning resources.  The further in advance you can do this the better.
1. We found out that users kept having their video stall.  The fix is to refresh the page but that knocked them out of the chat on the same page and they'd have to do it manually.  So we had to build an iframe that refreshed itself every minute or so.  And host that and work out the kinks. In less than 45 minutes.  The video was still served from video.mozilla.org.
I cant see any offsite content left on the pages specified. VERIFIED
Status: RESOLVED → VERIFIED
Whiteboard: sumo_only
You need to log in before you can comment on or make changes to this bug.