No matter how much I look this up all I get is the w3C File API which focuses on local files for the client.
What I'm trying to do is I have a server. I'm trying to use client-side javascript to grab the server hosted text file, a.txt, and display it to the innerDOM of an html page. My server directory look like this:
index.html
read.js
text files
a.txt
All I want to have happen is for, on the client side, the javascript read.js running in the index.html on onload to display the contents of a.txt. I figure that since a.txt will never be large, leaving it to the client is fine.
But I can't figure out how to do this and the W3C File API isn't offering me answers.
If I had to guess, somehow making sure index.html loads a.txt and then grabbing that via the file API might be the way to go but I'm not sure how to do that.
And I'll admit it, I'm a bit of a noob. If I'm invalidating browser sandbox or doing something impossible, please tell me. I just thought this would be so simple.
Also, I'd appreciate that if you were going to suggest AJAX, either don't, or explain it like I'm a baby because I really don't know.
Thank you all so much for your help.
Why file API is irrelevant:
Web applications should have the ability to manipulate as wide as possible a range of user input, including files that a user may wish to upload to a remote server or manipulate inside a rich web application.
From W3C File API.
So, File API is intended to be used to allow users to upload files from their clients into the server. On the other hand, AJAX is used to allow users to download files and other data from the server into their clients. And this is exactly what you need.
Refer to jQuery's ajax documentation.
I believe this page should help you out with your problem.
http://www.htmlgoodies.com/beyond/javascript/read-text-files-using-the-javascript-filereader.html#fbid=YhNukIHynD3
I would suggest using an Ajax call to the file on the server, since the response of the call will typically be the contents of that file.
Using Jquery this can be done by a simple
$.ajax({ 'url':'a.txt',
'success': function(r){
//display to innerDOM here, using r as the file
});
});
You simply want to display a txt file on the web page?
Do you know about server side includes?
That would be one possibility if you control the server.
If you really want to do it in javascript, then AJAX would be the way to go.
If it were me at that point I would figure out how to include and use jQuery to help with the ajax bits.
You will simply request the text file via its URL (you can get it to load in the browser right?), and then use jQuery to put that text into some DOM element.
Related
I have shared folder between in my server which will allow other server to send XML file to me and I want my script read this file auto without opening any page.
I know how to open and read the file.
But the issue how to auto load in the backhand.
you have to create a one page which will read the provided file and do the required actions , then share this URL and format with the team who will going to provide you the xml file.
It is very much like API Endpoint, Where you have to write the code which will handled request and in this scenario your Endpoint will treat as a server and XML file provider will treat as clients.
I hope this answer helps u.
Thanks
Traditionally, you need your server to periodically execute the script which reads the XML. That PHP will need to parse the XML and handle the changes.
Alternatively, the source of the API can use push notification to avoid polling with your server. The XML will be received whenever a change occurred on the server without the creation of a lot of useless requests, but the XML will be parsed as in the previous approach.
Last, but not least, you can use WebSockets for this purpose, or if both computers are in the same network, you can use sockets. Off course, a lot depends on the data source, whether you have access there, how modern is its technology and what does it allow you to do.
We're talking to a 3rd party to include some of their data on a website of ours, they want to do it either through an iframe which I don't prefer because of responsiveness reasons.
The other options they offer is the inclusion of a javscript file which will take a parameter to know what DOM element to put the results in.
Basically this gives them access to the javascript scope of our website in which if they wanted can do stuff like hide dom objects etc.
My question is, are there any security things I have to think off? Can they in their javascript for example write malacious code that in the end reads .php files from our server and get passwords from config files etc? Or is the only thing they can do DOM related?
They could:
Take control of users' cookies, including reading and modifying
them.
Redirect the user to any site they would like.
Embed any code they would like into the page.
They can't:
Access php files directly.
Access any server files directly.
Javascript runs in the browser and not on the server.
You're essentially giving them trusted XSS privileges.
If you can do something in a web browser (make posts, "browse" a page, etc), you can automate it using JavaScript. They won't be able to upload/modify your PHP files unless you (or your users) can.
To the user, you're giving them to capability to impersonate you.
To you, you're giving them the capability to impersonate users.
Can they in their javascript for example write malacious code that in the end reads .php files from our server and get passwords from config files etc?
They can do anything in the JavaScript code you're including on your page for them that you can do in JavaScript code on that page. So that could be just about anything you can do client-side. It includes (for instance) grabbing session information that's exposed to your page and being able to send that information elsewhere.
If you don't trust them not to do that, don't include their JavaScript in your page.
We're talking to a 3rd party to include some of their data on a website of ours
Have them make that information available as data, not code, you request via ajax, and have them enable Cross-Origin Resource Sharing for the URL in question for requests from your origin. Then, you know you're just getting their data, not letting them run code.
Note that using JSONP instead of CORS will enable them to run code again, so it would have to be true ajax with CORS if you don't trust them.
You shouldn't have to worry about PHP files, or config files but stealing session cookies or other XSS-style attacks could definitely be an issue.
Why can't/won't they provide data in the form of an API?
I am trying to search an outside url for content matching "title" and return the results to my HTML page in the background through Javascript. I have been using Javascript and not found any resources that resolve my query, maybe I'm asking wrong?
but I would basically search the document with :
var title = document.getElementsByName("title");
The hard part is connecting to the page and searching through the HTML source code.
TIA!
You can't generally get the content from an outside URL unless server specifically allows you to do so. But, you can do it from server side. You will be able to get the content of any URL from your server. Server must include an header in response with name access-control-allow-origin which contains patterns/name of your domain.
However, you can do it from server side anyway, unless you are blocked specifically by the server.
You will need to develop a solution in which you grab the content for your outside URL from your server. It can be anything like PHP, Node.js, C# etc. After receiving response from the external server, deliver it in response to the browser using AJAX or anything. Then you can play with it anyway you want using JavaScript or JQuery.
Important Note:
Make sure whatever you are trying to access in anyway, you are allowed to do so. If they (your outside URL) wants to share something with public, they must be providing some APIs or other solutions to allow you access to their content.
Research has led to to a solution, implementing a scraper. There are many in existence,scrapy for instance. Just a head's up for those with the same question.
I am making an android app and a website that downloads info from a php script. The php script compresses the data using gzcompress($dat, 9);.
I know how to uncompressed it in android, but how do you do it in javascript?
In this post:
Compress data in php and uncompress in javascript
sstringer mentions you can put a special header when using php's gzencode so jquery can automatically uncompress it. Is there a way for the way I am doing it?
Thanks
I looked into this myself once. I decided to go to the ajax route and then redirect.
If you know where the file is being stored on the server you could post that to a php script which decompresses it and saves the file somewhere. Next, return this in the ajax response and then just redirect the user to the saved, decompressed file.
There is a project on GitHub: https://github.com/gcanu/gzip.js
That might be what you are looking for.
I just implemented uploadify in my project, and I noticed what seems like an important security issue with the uploading process:
The folder in which the file should be uploaded is provided as a javascript argument, so client-side. If the user changes the script, and fills in a different folder (i.e. "/") for the upload, the file gets uploaded to the different folder.
There is an option in the config to filter the filetypes, but again it's provided on the client side ("fileExt").
So am I wrong to think this could lead to a possible hack? Uploading a php file anywhere in the Web Root and executing it seems easy.
Is it the desired behavior?
Should I just cross-check the upload folder in the uploadify.php file?
Should I send a notice to the uploadify makers?
I'm sure I'm not the first one to think about this. Oh, and the same goes for other config parameters, like sizeLimit and queueSizeLimit.
Just looked at the code (haven't installed it anywhere), and it certainly looks like this is a security problem. Looking at uploadify.php, I see this:
$targetPath = $_SERVER['DOCUMENT_ROOT'] . $_REQUEST['folder'] . '/';
Which means that passing "/" would put the file in the document root (i.e. the home directory of your website). Of course, the user could easily (for example) pass in a folder parameter like '../../etc' and a file named 'passwd'. Or, more trivially, he could upload a "logo.jpg" to the document root and, hey, now you've got porn for a site logo!
Of course, even if you sandbox the users, there are still lots of potential problems with allowing a user to arbitrarily upload a file to your server. What if they upload a .php file, then go to that file with their browser? They suddenly have the ability to execute arbitrary code on your server!
If you want to do this, you should force the user's uploads into a restricted directory (the realpath function will sanitize the path, in case the user created crazy paths with "../.." or whatever), and you should restrict the types of files allowed (i.e. to only ".jpg", ".gif", ".png" or whatever). Even then, a malicious user could DOS you by filling up your disk quota.
i just want to give my opinion about your post.
You forget a important thing in your analyse.
Developpers HAVE TO check variables in the server side script.
If you use javascript (like uploadify, or your own script) or if you don't use javascript (just a simple FORM in html), YOU HAVE to check the data in the server side script. So no matter if you are using uploadify or not for your security. Don't forget that it's easy to buid HTTP request and send it to the server. So the security of a web application not depends of the client
Thanks for your attention
GUIGUI
That is indeed a security issue, path traversal. You should email them and ask them to fix it.
You are free to put file anywhere using your server side script and your config. I never use their javascript config for such things.
I know this is a bit old topic, but here's a note from plugin developer:
Given the wide variety of scripting languages, server side validation is up to the users to code. We are developing the plugin to allow those who know what they are doing to use what ever language they want for the front end and back end. And creating new scripts to retrieve information makes it that little bit harder for other users to implement, for example those using aspx, java, codeigniter etc.. would need to rewrite major portions of the plugin.
You can read it full here.
Remember, server validdation is a must! You cannot ignore it, ever. This is what I've learnt reading SO and PHP manual.