jQuery: synchronously update progress bar as html page loads? - javascript

I have a script that sends emails (subscriptions). Processing takes long enough. The script outputs a log (of what is successfully sent to the moment) to browser.
I would like it to show progress bar also. How do I do that? There is no AJAX calls, page loads synchronously. I thought may be I should just output <script>...</script> tags every X email sendings to move progress bar, but I'm not sure it's cross-browser compliant. Is that a standard, that browser should execute Javascript as soon as it encounters some in the page body?

Yes, your idea is used very often and should work in most browsers - the standard is that javascript must be executed synchronously, unless specifically told not to by the async attribute.
So you can just put in a script tag every now and again to update the status bar. Gmail uses the same technique, as far as I know.

Related

How to execute onload function javascript from a python file?

I want to get data from html page, but the page has onload functions which aren't executed when I use the get method of requests.Session().
with Session() as s:
s.get('https://o2.amdm.pro/amdm/S/S/S/insure/Portfolio#/entityHandle=01%7CPD%7C00000000000001384776%7C0001%7C0001', stream=True)
My question is, how to execute those functions as if I was in a browser to get the missing data in order to fill the main div ? Or at least, load the page in a browser and get the html from this page fully loaded ?
My question is, how to execute those functions as if I was in a browser to get the missing data in order to fill the main div ?
You need tool with JavaScript support for that, if you want one similar in usage to python-requests I suggest giving a try Requests-HTML.
load the page in a browser and get the html from this page fully loaded
For that you need web automation tool, here I suggest trying Selenium.

Force a route cleanly with javascript

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.

How to use JavaScript variable in Haml?

I have a javascript function (available on all pages as it's included in application.js) that detects if the browser has Flash support and outputs true or false.
Now, I want to show a flash based price chart if true and a HTML/Javascript based chart if false.
At the top of a Haml page I try to pass the result of the javascript function to HAML like this:
:javascript
if (browserHasFlashSupport())
#{showFlashChart = true}
And use it in Haml further down on the page like this:
- if showFlashChart
# show flash chart
- else
# show html/js chart
But I can't get it to work as the ruby variable showFlashChart is "true" no matter what - but in console, the javascript function browserHasFlashSupport() returns true/false like it should, so I must be doing something wrong.
I guess it would probably be the best solution just to use the javascript functions "return true/false" directly in HAML like - if browserHasFlashSupport() if that's possible and the "right" way to do it?
I'd appreciate any help, thanks :-)
PS. Any tips on how to avoid the usage of inline javascript in my HAML file would be very welcome too.
The problem of your solution:
Your javascript function has to be run in a client's browser to detect if it has flash support.
Here is what happens when a user wants to get a page from your site:
User's browser sends request to your server.
Your server handles the request, compiles views(e.g. HAML).
Also rails adds <script> tags to the output html page. These tags will contain urls to your scripts (defined in application.js or others). Then the server responds with this html page.
User's browser loads compiled page from your sever.
The browser sees the <script> tags and automatically downloads javascript sources from specified urls.
And only now in the clients browser your javascript functions may be run.
You see that your haml template was rendered on the step 2 and your javascript function may be run only on step 5.
That is a lot simplified case. But it is impossible to make step 5 to precede step 2 (without use of ajax or cookies). That is why your way is impossible.
Hope this is quite descriptive.

Run a perl script on web site page load

I have a page that when loaded I would like it to run a perl script. Is this possible to do with javascript? I have never ran a perl script on the web before and the only way I have seen to do it is link to it.
There are 3 ways:
If it's a dynamic page (CGI or other), as long as your script backing the page is an executable Perl script returning valid HTTP response, you're good. If you need to execute a separate Perl script, you can do it using the usual system() call (ideally, the functionality should be a Perl library call so your script can then execute it without spawning a system call). This approach of course works with ANY language that the back-end script is written in, e.g. if it's a Java Servlet, or any other code, it can also execute a system call to your Perl script.
If it's a static HTML page, you can have an "onload" JavaScript event (or just a JS function call inside a <script> tag) which executes an AJAX call to a different dynamic page (say http://yourserver/scripts/run_script_X ) running the script as per previous bullet point.
Just to be clear, the script will be running on the web server and not in a browser/client system; so you need some sort of mechanism for allowing the results of the script to affect your web page if you wish to have such an effect.
$.ajax({url: 'http://yourserver/scripts/run_script_X'}); // jQuery example
As an oldie variation on the last approach, you can also have your page have a <IFRAME> whose URL points to http://yourserver/scripts/run_script_X (make the iframe small/invisible if you don't care about the results of running the script as per your comment).
<!-- The rest of your HTML code -->
<IFRAME
SRC="http://yourserver/scripts/run_script_X"
style="display: none;"
/>
Irelevant comment made prior to the comments on this answer:
Without a lot more context on what you want the page to be (CGI script, static HTML, etc...) and what you want the script to do and how you want the results of running the script to affect your page, it's hard to suggest anything more precise.

Refused to execute a JavaScript script. Source code of script found within request

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.

Categories

Resources