HTML link to either local network or domain name - html

In my web page, I want to link to another web server in my local network.
I use <a href="192.168.1.111:8080/index.jsp">to do this when I am in local network. However, when I access the website outside the local network, I need to use domain name. <a href="mydomain.com:8080/index.jsp">
How can I do this in same page of code if I would access it from both LAN and WAN.

Well, if it's an option, the easiest way to avoid this issue is using relative links. For example, if you're linking to another page on the same website, your link will always work if it's something like "../directory/some-web-page.html" rather than a full link with http included.
Otherwise, if you're linking to a completely different site, you could check whether your page exists on the local server using a very simple JQuery ajax request. If it doesn't exist, then assume you are not signed in to the same network and insert your remote domain name.
As discussed here, your simple ajax request can just fetch the HEAD of the locally hosted page, that way you're not fetching too much data and only confirming whether it exists. Your code could be something like this:
$( document ).ready(function(){
$.ajax({
url: 'path/to/your-file.html',
type: 'HEAD',
success: function() {
// page exists
// replace the href attribute with local host link
document.getElementById('your-link').setAttribute('href', 'path/to/your-file.html');
},
error: function() {
// page does not exist
// do nothing, so your link sends user to remote site
}
});
});
And then, in your HTML, just include the link to your remote site like so:
<a id="your-link" href="yourremotesite.com">This is a link</a>
This should work on both a local and remote server without having to change the code.
EDIT:
I had to jump out of bed because another answer was just nagging at me...
You can also try accessing window.location.host or window.location.hostname and testing that in an if-statement to determine whether your page is on the local host or remote server.
Anyway, I hope one of these solutions helps. Good night and good luck!

HTML:
link
javascript:
<script>
window.onload=myFunction;
function myFunction() {
var x = document.domain;
var a = document.getElementById('link');
a.href = x + "/index.jsp";
}
</script>

Related

How do I clear cached angularjs files

I have an angularjs based web application with some functionality deployed to users that I need to hide. I've added the code to hide it and successfully verified the controls are hidden when appropriate but there are still users who have the old version of the file and can perform the undesired activities. Is there a way I can control from the server the view file to refresh on the client? (The tester was able to clear their cache but it's a burden to the users in the field)
Thanks!
Scott
One way to handle this would be to version the files. For example, the following line in your index.html
<script src="abc.js" />
could be rewritten as
<script src="abc.js?v1" />
v1 is the current file version and should be changed for each deployment of your application when abc.js has changed.
Since index.html(the initial page) is obtained from the server, updations to abc.js will now be reflected on all your clients.
This would need to be automated in a huge application. You could use Grunt for this. You can refer the following answer on StackOverflow for automating this:
https://stackoverflow.com/a/20446748/802651
UPDATE
HTML views/templates are cached using $templateCache in AngularJS. Basically, when you request templates for the first time, browser requests the template from the server and puts it in the template cache. Any subsequent requests to the same template are served from the template cache.
If you do not want these to be cached, you could listen to the $routeChangeStart event inside app.run block to remove the specific templates.
app.run(function($rootScope, $templateCache) {
$rootScope.$on('$routeChangeStart', function(event, next, current) {
if (typeof(current) !== 'undefined'){
$templateCache.remove(current.templateUrl);
}
});
});
Reference: http://opensourcesoftwareandme.blogspot.in/2014/02/safely-prevent-template-caching-in-angularjs.html

Node js - socket.io - Linked Stylesheet not loading... port issue?

I have a working chat application ( tutorial here : https://www.youtube.com/watch?v=QISU14OrRbI ) hooked to mysql instead of mongodb.
All of my code in a paste, minus the css : http://pastebin.com/j5FLZyFP
I have always been able to link to a css file via the link element in the DOM head. I am wondering why this approach doesn't work in my example and if it has anything to do with which ports i am using. The server that serves the index.html page is running on port 8080, while my sockets server is running on port 9000. Should I be using the same port for both of them? If so, how do I do that?
Below are screenshots of my browser # 127.0.0.1:8080
I need 10 reputation to post more than 2 links, slap my wrist I suppose - https[colon][slash][slash]imgur[dot]com[slash]a[slash]22Vv5
I get served the page, but i am forced to press ESC to stop the main.css from getting transferred. Then the remaining requests come through. don't be concerned about inject.js, it represents the Wappalyzer extension and I have tried the example with Wappalyzer disabled.
Adding my CSS to a style tag works and isn't too much trouble to implement in my case, but it would be nice to solve this problem. Thanks.
Kamran Adil in the comments has answered this well. See linked question: Node.js - external JS and CSS files (just using node.js not express)
this worked just fine adding a new condition to test the request
var param = 'main'; /* Stylesheet file name */
if(req.url.indexOf('.css') != -1) {
fs.readFile('./styles/'+ param +'.css', function (err, data) {
if (err) { console.log(err); }
res.writeHead(200, {'Content-Type': 'text/css'});
res.write(data);
res.end();
});
}

Dojo 1.9 JsonRest remote url on a different server

I'm trying to get dojo to show Json data that comes from a remote web service. I need to be clear though - the web server hosting the html/dojo page I access isn't the same server as the one that's running the web service that returns the json data - the web service server just can't serve html pages reliably (don't ask!!).
As a test I move the page into the same web server as the web service and the below works. As soon as I move it back so that the html/dojo is served from Apache (//myhost.nodomain:82 say) and the web service sending the json is "{target:http://myhost.nodomain:8181}", then it stops working.
I've used FFox to look at the network & I see the web service being called ok, the json data is returned too & looks correct (I know it is from the previous test), but the fields are no longer set. I've tried this with DataGrid and the plain page below with the same effects.
Am I tripping up over something obvious???
Thanks
require([
"dojo/store/JsonRest",
"dojo/store/Memory",
"dojo/store/Cache",
"dojox/grid/DataGrid",
"dojo/data/ObjectStore",
"dojo/query",
"dojo/domReady!"
],
function(JsonRest, Memory, Cache, DataGrid, ObjectStore, query) {
var myStore, dataStore, grid;
myStore = JsonRest(
{
target: "http://localhost:8181/ws/job/definition/",
idProperty: "JOB_NAME"
}
);
myStore.query("JOB00001"
).then(function(results) {
var theJobDef = results[0];
dojo.byId("JOB_NAME").innerHTML = theJobDef.JOB_NAME;
dojo.byId("SCHEDULED_DAYS").innerHTML = theJobDef.SCHEDULED_DAYS;
});
}
);
Its true what Frans said about the cross domain restriction but dojo has this link to work around the problem.
require(["dojo/request/iframe"], function(iframe){
iframe("something.xml", {
handleAs: "json"
}).then(function(xmldoc){
// Do something with the XML document
}, function(err){
// Handle the error condition
});
// Progress events are not supported using the iframe provider
});
you can simply use this and the returned data can be inserted into a store and then into the grid.
Are you familiar with the Same Origin Policy:
http://en.wikipedia.org/wiki/Same-origin_policy
Basically it restricts websites to do AJAX requests to other domains than the html page was loaded from. Common solutions to overcome this are CORS and JSON-P. However, remember that these restrictions are made for security reasons.

Simultaneously download a file and update a database using jQuery Ajax

I have a link which is supposed to download a file, whilst simultaneously sending data to a PHP script via Ajax to update a database. The HTML for the link is:
<a class="rel_link" href="document.docx">Download</a>
And the jquery code is:
$("#downloadtable a").click(function(){
$.ajax({
url: "download.php",
type: "POST",
data: {dlname: dlname, dlaccount: dlaccount, dlmodule: dlmodule, dlemail: dlemail, dlsub: dlsub, dlpath: dlpath},
success: function(data){
$("#die2").detach();
}
});
});
Unfortunately the two don't seem to work simultaneously. If the jQuery is disabled, the document downloads perfectly. If the jQuery is enabled and the href attribute is set to href="#"', the jQuery works and the data is written to the database. However, if jQuery is enabled and the href is set tohref="document.docx"`, the file downloads but the data does not get passed to the database. The only error message I'm getting on the console is:
Resource interpreted as Document but transferred with MIME type application/vnd.openxmlformats-officedocument.wordprocessingml.document: "http://www.mysite.org.uk/downloads/document.docx".
Can anyone shed any light on how to simultaneously download a document and write to the database via Ajax?
Many thanks
If you switch the href to point to a php, you problem might be solved.
Then you can write into database, and initiate the download with the appropriate header() calls.
Look on Example#1:
http://php.net/manual/en/function.header.php

Access-Control-Allow-Origin error in a chrome extension

I have a chrome extension which monitors the browser in a special way, sending some data to a web-server. In the current configuration this is the localhost. So the content script contains a code like this:
var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function(data)...
xhr.open('GET', url, true);
xhr.send();
where url parameter is 'http://localhost/ctrl?params' (or http://127.0.0.1/ctrl?params - it doesn't matter).
Manifest-file contains all necessary permissions for cross-site requests.
The extension works fine on most sites, but on one site I get the error:
XMLHttpRequest cannot load http://localhost/ctrl?params. Origin http://www.thissite.com is not allowed by Access-Control-Allow-Origin.
I've tried several permissions which are proposed here (*://*/*, http://*/*, and <all_urls>), but no one helped to solve the problem.
So, the question is what can be wrong with this specific site (apparently there may be another sites with similar misbehaviour, and I'd like to know the nature of this), and how to fix the error?
(tl;dr: see two possible workarounds at the end of the answer)
This is the series of events that happens, which leads to the behavior that you see:
http://www.wix.com/ begins to load
It has a <script> tag that asynchronously loads the Facebook Connect script:
(function() {
var e = document.createElement('script');
e.type = 'text/javascript';
e.src = document.location.protocol +
'//connect.facebook.net/en_US/all.js';
e.async = true;
document.getElementById('fb-root').appendChild(e);
}());
Once the HTML (but not resources, including the Facebook Connect script) of the wix.com page loads, the DOMContentLoaded event fires. Since your content script uses "run_at" : "document_end", it gets injected and run at this time.
Your content script runs the following code (as best as I can tell, it wants to do the bulk of its work after the load event fires):
window.onload = function() {
// code that eventually does the cross-origin XMLHttpRequest
};
The Facebook Connect script loads, and it has its own load event handler, which it adds with this snippet:
(function() {
var oldonload=window.onload;
window.onload=function(){
// Run new onload code
if(oldonload) {
if(typeof oldonload=='string') {
eval(oldonload);
} else {
oldonload();
}
}
};
})();
(this is the first key part) Since your script set the onload property, oldonload is your script's load handler.
Eventually, all resources are loaded, and the load event handler fires.
Facebook Connect's load handler is run, which run its own code, and then invokes oldonload. (this is the second key part) Since the page is invoking your load handler, it's not running it in your script's isolated world, but in the page's "main world". Only the script's isolated world has cross-origin XMLHttpRequest access, so the request fails.
To see a simplified test case of this, see this page (which mimics http://www.wix.com), which loads this script (which mimics Facebook Connect). I've also put up simplified versions of the content script and extension manifest.
The fact that your load handler ends up running in the "main world" is most likely a manifestation of Chrome bug 87520 (the bug has security implications, so you might not be able to see it).
There are two ways to work around this:
Instead of using "run_at" : "document_end" and a load event handler, you can use the default running time (document_idle, after the document loads) and just have your code run inline.
Instead of adding your load event handler by setting the window.onload property, use window.addEventListener('load', func). That way your event handler will not be visible to the Facebook Connect, so it'll get run in the content script's isolated world.
The access control origin issue you're seeing is likely manifest in the headers for the response (out of your control), rather than the request (under your control).
Access-Control-Allow-Origin is a policy for CORS, set in the header. Using PHP, for example, you use a set of headers like the following to enable CORS:
header('Access-Control-Allow-Origin: http://blah.com');
header('Access-Control-Allow-Credentials: true' );
header('Access-Control-Allow-Headers: Content-Type, Content-Disposition, attachment');
If sounds like that if the server is setting a specific origin in this header, then your Chrome extension is following the directive to allow cross-domain (POST?) requests from only that domain.