I want to open a page using window.open link to hit the servlet and from which I need to hit another servlet link, but the noticeable thing is that I cannot modify anything in those servlets.
Is it possible for me to do these two navigations from my first JSP page itself using Javascript or jQuery?
Inside serverJsp.jsp add this code at the end( after all your other code is done).
response.sendRedirect("page2.jsp");
I would prabably try and avoid having a sequence like this exposed to the browser, can you do this all on the server side?
Having a web browser make all those requests would have a big performance hit if they are on a slow connection.
Alternatively, if you need to do this in the browser have the server return a http 301 status code with the location field in the header to refer to the next location you want the browser to hit.
Using the status code method would be the lightest weight on the browser, if you get involved with the browser having to interpret javascipt it will be a lot slower.
Use the window.onload event to open your other servlet page.
Related
I'm working with a legacy app's UI and the path that links to this app is a default:
something/fldr
Whenever that page loads it forces a fldr/landing.asp page. We want to get it to go to other.asp instead of landing.
My approach for this is to use:
if (document.readyState === "interactive") {
if(location.href == 'https://www.something.com/fldr'){
location.href="https://www.something.com/other.asp";
}
}
Doing this causes a page stutter, where the landing.asp loads, shows for like 2 seconds and then refreshes to the correct page.
Is there a standard method for doing something like this in JS or jQuery? I feel like there is a way to make the page hang up until the if statements executes rather than try to load the wrong page. But I can't for the life of me remember what it is. I've handled this on the back end by forcing the correct page to return in the API but I still feel like this is something that can be resolved with only JS.
Note: The route names are made up since this is a stripped down problem of a legacy app.
JavaScript (when running in a browser) is a client-side technology.
That means it cannot run without the page partially loading after the page has been served and sent to the user's browser (client). The browser begins loading resources and parsing scripts and code, and your script will execute in the order it is parsed. This is, in fact, the delay you're experiencing.
While you may possibly tweak this to make the location.href change
execute in some earlier part of this process, there is no way to avoid
a partial page load prior to the client-side redirect you have
implemented.
Essentially, there is a better way to do this, one which will reduce the redirect delay to be imperceptible to a user.
Making this change at the web-server level is the ideal solution; however, first consider, is that even needed?
First, before implementing a redirect, I would suggest to look in the IIS settings and see if there is a default document set to fldr/landing.asp;
You can then just change that setting to make the default document to what you need.
Here's an example for IIS how to do this.
If there is not a default document or if there is some other code or application logic that is forcing landing.asp to load, then you would set up a 301 Permanent Redirect for that URL on the web server.
Here are IIS docs on setting this up.
IF for some reason the above options are unavailable to you (don't have access to web server, etc.), then the best you can do is ensure that script is the first thing in the page before any other scripts, stylesheets, etc., are loaded.
Another hacky thing that might work is just replacing the entire content of landing.asp with other.asp and call it a day :)
That is a last resort of course, and hopefully you can just change the default document and that will handle it.
I need to make it so that when users visit a web page like example.com/news it automatically brings them to a different website like cnn.com without them having to click anything. It would be preferable if they would not even see the original web page and it would bring them directly to the other site (cnn.com in this case) I think I can use the onload event in html but I have little experience in javascript and don't know what code to use in order to accomplish this task. Thank you!I do not want to use jquery if possible.
Just one line of code (inside script tags)
<script>
window.location.href = "http://exampleurl.com";
</script>
You would be better off using headers. Depends what server side scripting language you are using. For PHP you would have the following:
header('Location: http://www.example.com/');
I have the following function that activates when I click on some links:
function showPage(page) {
var History = window.History;
History.pushState(null,null,page);
$("#post-content").load(page + ".php");
}
The content of the page updates, the URL changes. However I know I'm surely doing something wrong. For example when I refresh the page, it gives me the Page Not Found error, plus the link of the new page can't be shared, just because of the same reason.
Is there any way to resolve this?
It sounds like you're not routing your dynamic URLs to your main app. Unless page refers to a physical file on your server, you need to be doing some URL rewriting server-side if you want those URLs to work for anything other than simply being placeholders in your browser history. If you don't want to mess with the server side, you'll need to use another strategy, like hacking the URL with hashes. That way the server is still always serving your main app page, and then the app page reads the URL add-on stuff to decide what needs to be rendered dynamically.
You need to stop depending on JavaScript to build the pages.
The server has to be able to construct them itself.
You can then progressively enhance with JavaScript (pushState + Ajax) to transform the previous page into the destination page without reloading all the shared content.
Your problem is that you've done the "enhance" bit before building the foundations.
Is it impossible to create a browser back button, using a form or link, when a users javascript is disabled?
Without server-side-scripting is not possible.
but you can show a message like this:
1)
<noscript>
Sorry, I can’t show you that information unless you enable
Javascript for your web browser.
To go back to where you were, just click/tap your “back” button.
<style type="text/css">
#main-content { display:none; }
</style>
</noscript>
2)
or a page like this:
http://saveyourself.ca/help-no-javascript.php
The easiest way to do this is on the server side. If you can get the HTTP Referrer (this is available in many server side languages), then you can build a link and append it to the page's regular HTML.
Without server-side-scripting? No. It's not possible.
However, if you're able to run server-side-scripts, then you could save the referrer and create a link yourself (Back). Note that some browser won't send a referrer.
I believe you can't use any javascript commands when it's disabled. However you may still use your browsers back button (not 100% on this since I've never tried it) but if the user has javascript disabled there are many things that won't work on the website. And the big websites usually won't allow users to do much if they don't have javascript enabled. 1 example is storing cookies and whatnot.
However, there are some ways of doing this using PHP.
A server-side could take HTTP_REFERER and add it dynamically to the current page. But if you know where they will most likely be coming from, you can simulate a back button by putting the most likely return destination there as a link. More
In WebKit I get the following error on my JavaScript:
Refused to execute a JavaScript script. The source code of script found within request.
The code is for a JavaScript spinner, see ASCII Art.
The code used to work OK and is still working correctly in Camino and Firefox. The error only seems to be thrown when the page is saved via a POST and then retrieved via a GET. It happens in both Chrome/Mac and Safari/Mac.
Anyone know what this means, and how to fix this?
This "feature" can be disabled by sending the non-standard HTTP header X-XSS-Protection on the affected page.
X-XSS-Protection: 0
It's a security measure to prevent XSS (cross-site scripting) attacks.
This happens when some JavaScript code is sent to the server via an HTTP POST request, and the same code comes back via the HTTP response. If Chrome detects this situation, the script is refused to run, and you get the error message Refused to execute a JavaScript script. Source code of script found within request.
Also see this blogpost about Security in Depth: New Security Features.
Short answer: refresh the page after making your initial submission of the javascript, or hit the URL that will display the page you're editing.
Long answer: because the text you filled into the form includes javascript, and the browser doesn't necessarily know that you are the source of the javascript, it is safer for the browser to assume that you are not the source of this JS, and not run it.
An example: Suppose I gave you a link your email or facebook with some javascript in it. And imagine that the javascript would message all your friends my cool link. So, the game of getting that link to be invoked becomes simply, find a place to send the javascript such that it will be included in the page.
Chrome and other WebKit browsers try to mitigate this risk by not executing any javascript that is in the response, if it was present in the request. My nefarious attack would be thwarted because your browser would never run that JS.
In your case, you're submitting it into a form field. The Post of the form field will cause a render of the page that will display the Javascript, causing the browser to worry. If your javascript is truly saved, however, hitting that same page without submitting the form will allow it to execute.
As others have said, this happens when an HTTP response contains a JavaScript and/or HTML string that was also in the request. This is usually caused by entering JS or HTML into a form field, but can also be triggered in other ways such as manually tweaking the URL's parameters.
The problem with this is that someone with bad intentions could put whatever JS they want as the value, link to that URL with the malicious JS value, and cause your users trouble.
In almost every case, this can be fixed by HTML encoding the response, though there are exceptions. For example, this will not be safe for content inside a <script> tag. Other specific cases can be handled differently - for example, injecting input into a URL is better served by URL encoding.
As Kendall Hopkins mentioned, there may be a few cases when you actually want JavaScript from form inputs to be executed, such as creating an application like JSFiddle. In those cases, I'd recommend that you you at least scrub through the input in your backend code before blindly writing it back. After that, you can use the method he mentioned to prevent the XSS blockage (at least in Chrome), but be aware that it is opening you to attackers.
I used this hacky PHP trick just after I commit to database, but before the script is rendered from my _GET request.:
if(!empty($_POST['contains_script'])) {
echo "<script>document.location='template.php';</script>";
}
This was the cheapest solution for me.