13

I'm running Firefox 61.0 on Arch Linux. When viewing the source of a page, I frequently (but not always, estimated 20% of the time) see the source code of the login page when I'm browsing a website that requires me to log in. This happens when I'm browsing localhost. The source code of each page is generated on the server, this is not a problem with the DOM being manipulated. It happens using Django as well as PHP. Example:

LOGIN PAGE:

<html>
<title>Login</title>
<body>
Login please: [    ]
</body>
</html>

HOME PAGE:

<html>
<title>Welcome USER NAME</title>
<body>
Good day, USER
</body>
</html>

After I have logged in and I am on the homepage, I hit CTRL+U, it will show me:

<html>
<title>Login</title>
<body>
You are logged in as USER
</body>
</html>

In other words, it isn't taking the previous page from its cache; it seems to somehow try and fetch the source code of the page I'm on but it is redirected to the login page.

NOTE: if I run INSPECT ELEMENT on the page then I do see the right source code. The problem is only with VIEW SOURCE. This does NOT happen in Chrome or other browsers, just in Firefox.

Any idea why this could happen?

To clarify: these are two different pages. The login page is login.php and the home page is index.php. When I CTRL+U on index.php, Firefox shows me the source code of login.php, even though I am already logged in.

  • Have a look at the HTTP headers that are being sent by Firefox to the page normally and in view source. Potentially Firefox might not be sending a cookie header or similar when viewing source, which could be changing the output of the same endpoint.. just as a guess. – roryrjb Aug 16 '18 at 19:21

7 Answers7

3

Apparently, this has always been an issue with Firefox's "view source". Here's a bug that was reported 13 years ago describing the process by which Firefox loads the page's source code by refreshing/re-requesting the whole page.

It is possible that an uncached version of the page is being downloaded, and thus, showing different results for the debugger and the source. It all depend's on how the login data is being handled (cookies, session variables, server variables, etc.)

Here's another Steckoverflow question on a related topic. I hope this can give you an idea on how to solve the issue you're having.

Niche
  • 967
  • 5
  • 23
  • 1
    Ah, that's why! Thanks, annoying that this is a 13 year old bug but good to know that this is an issue with FF... I had been going crazy with this issue for a while. I'll use Chrome for now when I need to work around this issue. –  Aug 19 '18 at 04:18
  • Followed the links. There is no real solution in any of them.. – Brobic Vripiat Mar 06 '21 at 19:42
2

I had the same issue. In current FF68 it is an option in the preferences in the dev tools. This has to be unchecked to send your cached login cookie.

enter image description here

enter image description here

Jin Lee
  • 2,245
  • 10
  • 23
  • 58
Winfo
  • 29
  • 2
2

As of March 2021, FF 86 there is a workaround:

  1. Open the Web dev tools (F12)
  2. Go to the Network tab
  3. Refresh
  4. Select the row with the request of the page (usually the first)
  5. Right mouse button -> Copy -> Copy Response
  6. Paste in your favorite editor

You will see the unmodified source.

freefaller
  • 17,790
  • 6
  • 50
  • 80
Ognyan
  • 12,916
  • 4
  • 61
  • 73
0

The login process is changing the html in the page. Quite often, in a login scenario, this is done with a form. But the general idea is to give you access to something once you've logged in. This can mean new information in the same page. It's the same one as the home (perhaps) or login page. The back end process checks the login information and then, if it matches, will send new html to replace the html in the page. There is more than one way to do it and more than one idea regarding what a website provides as a result of logging in. For example, I built a website with login that - once someone is logged in - their order forms are filled out automatically. They can also change their profile information. But the page doesn't change. I've also built pages that totally replace the html with a new page that allows access to whatever the registered user is allowed to access.

Roger F. Gay
  • 1,550
  • 1
  • 18
  • 25
  • Thanks but the page _does_ change completely; the files are two very different files (I"m browsing localhost, not the internet). I've added this clarification. –  Aug 14 '18 at 04:44
  • Showing the source code shows you the original source code. Using inspect shows you the current page. Reading your question now; Are you getting a 304 return code in network? – Roger F. Gay Aug 15 '18 at 10:39
  • Web pages can also be modified on the server. PHP does that quite naturally, and it should deliver content that it builds in response to a form - such as a typical login form. It could be that the PHP is building the login form on the fly and the response. From what you've explained above though - seems like there's something not quite right. It would be helpful if we could see the whole application, including the PHP code. – Roger F. Gay Aug 16 '18 at 12:03
0

I've seen this behavior as well and it happens when applications (server-side) don't properly handle caching.

What might happen is that your index.php redirects non-logged-in users to login.php. Combine this with a hit on index.php page that includes itself as a resource (eg. in an image or xmlHttpRequest) without supplying credentials and your application redirects the browser (for this resource) to login.php. This second hit (for the resource with same URL as the page, no proper credentials and a response with incorrect headers) will overwrite the first in your browser cache, making your browser display the second response (redirect to login.php), not the first (actual index.php) when you view source.

I hope this is clear, otherwise I'll try to add an example. You can use external tools such as redbot to check cacheability of the index page (check both with and without credentials). Also, if you use the developer-console (network-tab) you should enable 'Persist Logs' and verify the requested URLs and their cache status. Alternatively, if this is a web-application you control, check for any Cache-Control and Last-Modified headers being send in the application.

Sjon
  • 4,605
  • 6
  • 24
  • 42
0

You can also re-type the url in the address bar in the view source window.

Step by step:

  • right click and click "View Page Source"
  • the source window appears (in this case with the unwanted source code from the loginpage)
  • type in de addressbar of the "Page Source Window" the url of the page you want to see the source code from
  • Now you see the code and there is not another redirection to the login page (at least in my projects)
medicalbird
  • 87
  • 7
  • Can you give more details? As it stands, this doesn't work, otherwise I've misunderstood what you're saying we should do – freefaller Apr 06 '21 at 14:19
  • Ofcource @freefaller .. - right click and click "View Page Source" - the source window appears (in this case with the unwanted source code from the loginpage) - type in de addressbar of the "Page Source Window" the url of the page you want to see the source code from - Now there is not another redirection to the login page (at least in my projects) – medicalbird Apr 14 '21 at 17:03
  • Sorry, still doesn't help. If I re-enter the URL in the address bar, I get the page, not the source... even if I use `view-source:` prefix. Plus it doesn't help for pages which have been driven by form data – freefaller Apr 15 '21 at 08:05
0

Slight modification to Ognyan's answer above, but you can't add pictures to a comment. Do what he says:

  • Open dev tools
  • Load page
  • Find the page load (should be the first request on the Network tab)
  • Click, then in the details section to the right click on the Response section

Now, instead of copying/pasting anything into an editor, look for the "raw" toggle button and switch it on. You'll see the raw source:

enter image description here

Daniel L
  • 494
  • 4
  • 7