Can I use "--allow-file-access-from-files" when starting chrome app? - file

I am trying to load a simple .txt file content with a Chrome App (using file: protocol); I need to show its content for the user in a <div>. I need to open the file from a path typed in a input text (or defined in a string variable).
The flag --allow-file-access-from-files works fine when I load my .txt file content through Chrome browser. However, when I try to do the same with my Chrome App launcher (I have applied --allow-file-access-from-files flag on it), it keeps telling
Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, https, chrome-extension-resource.
I dont know if I am missing something or if it is impossible for chrome app.
My user will work with the app in Windows platform.

I finally figured out that --allow-file-access-from-files does not work at all in my case.
I started coding using fileSystem and made something like the recomended in this question, following the main example. Now I am able to work with files in a directory asking the user to choose it only one time.

Related

Is there a way to disable chrome automatically redirecting to https? My situation is a bit tricky

Lets say the name of my service is 'redyellowgreen'
my server only accepts requests from redyellowgreen.world
I am currently using a mac, and I have changed my host file using
sudo vim /private/etc/hosts
command to access localhost in local.redyellowgreen.world
untill some point last week, I was able to access local.redyellowgreen.world just fine in incognito mode in Chrome.
But for some reason, I can't now....
when I try accessing localhost:3000, it works just fine but no response from server. when I try local.redyellowgreen.world:3000, It does not work and shows 'This site can’t provide a secure connection' Error and 'ERR_SSL_PROTOCOL_ERROR' code in chrome
I tried deleting in domain in hsts, flushing dns, removing cache and many other things.
Is there way to disable this auto-redirect?

File default.css appears in browser after being deleted from server

I am making some changes to the css file for a website and I found out that my changes are disregarded.
In order to diagnose the problem, I deleted the only css file I have (default.css) from the server.
To my surprise, all web browers (Chrome, Firefox, IE11) are still capable of seeing and downloading the file. So, if I go to www.example.com/default.css, I can download the file despite the fact it is not there anymore! I used the command Ctrl + F5 to clear the local cash from browsers and reload the file default.css, but the file is still there and it contains the old version. I also used Ctrl + Shift + Del to clear everything in IE browser. Earlier today I created the file .htaccess to redirect example.com to www.example.com. I also use the services of cloudflare.
If I upload to the same location a different file, default2.css, I can view it correctly.
Any idea who delivers to me the old file? I suspect it may be cloudflare. I host my website on runhosting.com
Thanks,
Nick
Did you purge the file in CloudFlare?
CSS is a file CloudFlare caches & you would want to purge it if you make a change to static content we cache.

select file in Safari in Protractor

Executing this code in Safari doesn't work, but it works in chrome and firefox:
var pathToFile = path.resolve('./scripts', file);
element( by.css('input[ng-file-select="onFileSelect($files)"]')).sendKeys(pathToFile);
In digging around it looks like it's not possible to interact with file inputs in this way in Protractor running on Safari. Does anyone know of a workaround in Safari to put a file path in an input?
This is due to a leaky abstraction, which requires a Safari specific solution:
I guess the workaround for those that really want to do file upload for SafariDriver would be not to do it natively via SafariDriver but by using external code libraries to perform the upload via HTTP/HTTPS (POST) requests (combining any other form data in addition to the file being uploaded/sent), then get response and check whether upload succeeded or not, then go back to SafariDriver code and navigate to next page to check upload succeeded or not, and/or to continue from there for the next steps in the automation.
This approach would be similar to the file download method using HTTP requests externally that has been mentioned in various posts in WebDriver and Selenium user Google groups. Here, it's just the inverse, doing upload instead of download.
Though if the upload requires a session (cookie), then you can extract Selenium session cookie and use with HTTP request. Or if session is stored with session ID in URL, extract that and pass along with HTTP request.
References
Selenium Issue 4220: The SafariDriver does not support file uploads
How to upload file using Selenium when the file input is hidden?
Access is denied error in IE while file uploading
Changing the value of input file
Chrome file upload bug: on change event won't be executed twice with the same file
Selenium IDE 1.4.1 throwing security error when uploading a local file
Dynamically submitting a file upload form in IE10 using jQuery

Origin null is not allowed by access-control-allow-origin on Chrome

I'm developing a website to be used from a DVD, so I cannot rely on http:// protocol. The HTML pages use jQuery and knockout.js and load data from the JSON file using $.getJSON.
This runs fine on Firefox but I get an origin null is not allowed by access-control-allow-origin on Chrome. I've looked many SO answers on this but I cannot force the users to start Chrome using additional command line parameters or putting the site on HTTP web server.
Is there a way to let Chrome open local files?
I know this might be late, but I in the mist of a similiar problem. I have a solution for JSON (which I will share), but not for XML.
My solution was to use a javascript loader (ex: HeadJS) which does a great job for an application needing to run offline. I would create a file with .js in this manner.
var JSON = {
Field1: "Text",
Field2: "Text2"
}
Then I would use the loader. We actually allowed the user to choose which data they wanted and loaded that particular file.
Hope this help someone else.

How do I make my Apache 2 server force a browser to open a file transfer dialogue?

How do I make my Apache 2 server force a browser to open a file transfer dialogue if the URL points to a file with a .pln or .psa extension?
I have a simple LAMP server with CentOS 5, Apache 2, MySQL 5, PHP 5, recently built CentOS 5.2 i386 installation CDs. My web application generates files to be downloaded and imported into a custom application. The file extensions are .psa and .pln. How do I make my server force the browser to open a file transfer dialogue? If I point my browser to a .psa or .pln file on the Apache 2 server, the file's content is displayed in a pop-up window as simple text. I want a file transfer dialogue.
The web-app I am working on is deployed on another web-server and handles the .pln and .psa files as desired. I cannot compare server configuration files because I do not have administrator access to the working server.
How do I change my server's behavior? Does this require code changes to my web-app code (such as sending explicit headers)? If so, why does it work against the other server? Can code changes be avoided by configuring the server's default behavior?
You should be able to use the FilesMatch directive to add the necessary header.
<FilesMatch "\.(?i:pin)$">
Header set Content-Disposition attachment
</FilesMatch>
I tried several configuration changes which had no apparent effect.
I added the following line to my /etc/httpd/conf/httpd.conf file:
AddType application/octet-stream .pln .psa
I restarted the Apache server and it had no effect.
I added the following lines to my /etc/httpd/conf/httpd.conf file:
ForceType application/octet-stream
Header set Content-Disposition attachment
ForceType application/octet-stream
Header set Content-Disposition attachment
I restarted the Apache server and it had no effect.
If you have Firefox (and if not, why not?) install Chris Pedericks Developer Toolbar, and check that the headers are actually being set correctly. If so, it may be the fault of the browser. As I said, you can't be certain that any given browser will "correctly" interpret the response headers. What browser are we talking about here anyway?
If the headers aren't being set correctly, you may need to re-check your httpd.conf file. Possibly the directives you added aren't in the correct section? (e.g. under the wrong <Location > directive)
Forcing a browser to do something is always a tricky proposition, since the browser can ignore you and do what the hell it likes
That said, most browsers will prompt the user with a "save as" dialog box if the "Content-type" header is set to "application/octet-stream". Either write a simple wrapper CGI that serves up the requested file with the correct header, or fiddle with Apache2's mime-types (look in the config directory.)

Resources