306916 - View Source on page within password protected website shows source of login page instead.

Status: RESOLVED INCOMPLETE

(Toolkit :: View Source, defect)

Description

[ravind]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

I'm a web developer and Firefox is my browser of choice, both for surfing and
developing sites, which is why this bug is particularly frustrating. I have a
password protected website, developed in ASP.Net. Each page on the site checks
for the presence of a cookie, and if this is absent, or has been modified, it
redirects the user to the login page. Often, while editing one of the internal
pages, when I try to view the source, the browser shows me the source of the
login page instead.

E.g. I try to view the source for
http://ravind.homedns.org/rishivalley/people.aspx?id=48 (you need to login to
view this page)
Instead, the title of the view-source window reads:
view-source: - Source of:
http://ravind.homedns.org/rishivalley/login.aspx?rd=%2frishivalley%2fpeople.aspx
This is the page you would be redirected to if you weren't logged in.
It seems like the browser tries to reload the page, rather than show the source
from the cache. Additionally, the cookie is not returned to the server while
trying to reload the page and this causes the server to return the login page
instead, which is then displayed in the view-source window.

Reproducible: Sometimes

Steps to Reproduce:
1. Login to a website
2. Click on internal pages, requiring login, and try viewing the page source.
3. More often than not, Firefox shows the source of the login page instead.

Actual Results:  
I was shown the source code for the login page.

Expected Results:  
Show me the source code of the page I am currently viewing.

I have encountered this problem on different machines, while viewing more than
one website, hosted on different servers.

Comment 1

[zug_treno]

Related to Suite bug 213099 -> Suite bug 166786?

Comment 2

[Gus Heck]

I noticed a problem much like this, and after bouncing it off of some
colleagues, we eventually found bug 166786 which has an interesting discussion
of the matter. 

When I checked about:config It turned out that somehow my
browser.cache.disk.enable and browser.cache.memory.enable got set to false. I
don't remember doing any such thing myself, so either I am forgetful (quite
possible) or perhaps one of my extensions did something to my settings. 

My current extensions include: 

Checky 2.5
AutoForm 0.5.7
Web Develper 0.9.3
Html Validator (based on Tdy) 0.6.2
Reload Every 0.6.1

It seems that the disk.cache one is the one that actually causes this behavior,
however and as noted in the referenced bug it really seems all wrong that a
re-request should be performed to view the source. The most glaring reason that
this is wrong is the source may change depending on when the request is made if
the page is dynamically generated, so you could be looking at source that does
NOT produce represent the graphical representation in front of you. 

In my opinion the source should be recalled from memory in it's pristine form. 

I'm sure this gets trickier for source of pages shown after use of the back
button. I wouldn't advocate storing every page ever browsed in memory, so maybe
each user initiated request should dump what source is in memory onto disk...

Of course ajax type stuff mucks it up too, so perhaps it should be the case that
one can get either the source that resulted from the last user request, or
source that coresponds to the current DOM model...

In any case it seems very key for web designers or developers to be able to find
out what source produces the page you are looking at, or to be able to find out
what source it was that the server gave you when you asked for the page. The
current implementation appears to do neither.

Comment 3

[Gus Heck]

Hey look at that... the bug that was mentioned in our local IRC is actually the
same bug mentioned in the preceeding comment. :) 

Comment 4

[Peter Leonard]

There are a slew of bug reports relating to this - Bug 251231 is one of them.

Comment 5

[Peter Leonard]

Bugs I've found to date relating to this:
Bug 251231
Bug 306916
Bug 307089
Bug 321291
Bug 340120

I'll bet there are more - this was simply a search in Bugzilla for "view source". 

Comment 7

[Jeffrey Baker]

Whoops, duped to the wrong parent.  Geez, I'm on fire today.

Comment 8

[Matthias Versen [:Matti]]

Reporter: IS this still a problem with FF3 ?

Comment 9

[Tanner M. Young [:tmyoung]]

Is this still an issue with the latest version of Firefox?  If it is not, this should be resolved as INCOMPLETE.

Comment 10

[Gus Heck]

on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729) I did the following:

1. Requested a page from my apache server while tailing the log file and saw the log entry.
2. View source on the file just requested, no access logged.
3. Toggled the disk.cache.enabled to false 
4. Requested a different page, saw the log file entry
5. Viewed source on the second page, no access logged.

So it appears that unless authenticated pages are treated specially by view source, 3.5.7 is not re-requesting upon view source. 

I also did the following:
1. Logged into http://www.lotustalk.com/forums , 
2. went to my personal messages
3. Did a view source. 

The source returned contained my username (still loggeed in), and did not appear to be a login page.

I suspect this bug has been fixed in the course of other changes.

Comment 11

[Tanner M. Young [:tmyoung]]

Since it is working for both of us, I will resolve as INCOMPLETE.