search

laurentj / slimerjs

A scriptable browser like PhantomJS, based on Firefox
http://slimerjs.org
Other
3k stars 258 forks source link

Support of --web-security #37

Open laurentj opened 11 years ago

laurentj commented 11 years ago

the title says all

CMCDragonkai commented 11 years ago

So by default is SlimerJS web-security true or false?

laurentj commented 11 years ago

True of course...

CMCDragonkai commented 11 years ago

So right now, it cannot be turned off? Sorry if this is a stupid question.

laurentj commented 11 years ago

No, else this ticket would be closed ;-) And I didn't investigate yet to know how to deactivate it into gecko...

DarrenCook commented 11 years ago

Is there a workaround for this in the meantime? I'm getting complaints about a self-signed certificate when trying to test an https site. (I'm also getting complaints about it being expired, and being for a different domain name, but those are things I can fix by regenerating the certificate; its self-signed-ness isn't so easy to get around.)

laurentj commented 11 years ago

@DarrenCook you did a comment on the wrong issue. What you want is the option --ignore-ssl-error. see issue #26. However this is not yet implemented (and not easy to implement), and the workaround is to use a Firefox profile (see doc) in which the certificate has been accepted.

laurentj commented 10 years ago

I would like some examples where this disabling is really needed....

g0morra commented 10 years ago

One example would be dealing with iframes at the page.evaluate() level. With web security turned on, the same origin policy will block you from doing anything with the DOM in iframes, so you have to switchToFrame() for each action you want to take on different iframes in the same window. If you want to simulate moving the mouse over an iframe, or even worse a series of nested iframes, then this is maddening. With web security turned off, you can query and manipulate the contents of every iframe without leaving the main document. You can also easily get accurate offset values for elements in iframes compared to window.top, without having to walk up the frame stack and add up the offsets manually.

However a lot of the same origin problems can be solved by writing code with chrome privileges to get the values you need, without having to disable websecurity.

In terms of PhantomJS parity, with PhantomJS I've found many situations where the same origin policy still blocks me from certain iframes, even with web security ostensibly turned off (notably nested Google or Doubleclick iframes with javascript urls).

Lukich commented 10 years ago

I second g0morra's reply. I'm currently working on automated page tester which has to make sure all login fields are in place, and it breaks whenever there is an iframe form a different domain. And the solution involving switching frames, while possible, is quite cumbersome.

laurentj commented 10 years ago

@gomorra

so you have to switchToFrame() for each action you want to take on different iframes in the same window

yes, this is how you should do. Disabling security is not very recommended. Behavior can changed (imagine a web page loading a iframe containing a malicious page).

If you want to simulate moving the mouse over an iframe,

Well, webpage.sendEvent() does not need to switch between frames...

However a lot of the same origin problems can be solved by writing code with chrome privileges to get the values you need, without having to disable websecurity.

Probably we could improve the API by providing new methods ?

And/Or provide a better API to manipulate content in frames ?

@Lukich

I'm currently working on automated page tester which has to make sure all login fields are in place, and it breaks whenever there is an iframe form a different domain

IMHO, doing test should be done in same security context as a "true" browser. Else you are not sure that your web page will have the same behavior than in a true browser.

@Lukich and @gomorra : I think that disabling security for what you want to do is not the good solution. Disabling security is just a workaround. The best solution is to propose improvements in the API to ease some tasks.

ckedwards commented 10 years ago

I would like this feature as well. When using slimerjs with "http://mywebsite.com" everything works fine. However in order to simplify some tooling I would prefer not to require everyone who runs the tool have a web server. So instead I called "file:///path/to/mywebsite/index.html". But this does not work because I get a security violation since I need to get a file with a "../" url. With phantomjs I was able to get this working by disabling security (but I had to punt on phantom because it does not support webGL).

blak3mill3r commented 9 years ago

This happened to me while trying to use slimerjs to test clojurescript code using core.async.

The cause of the error is not made clear in the error message. FWIW, the code I am testing does not connect to a remote host.

The symptom is that slimer hangs with the only output being "Error: The operation is insecure." which is not at all helpful to me in trying to sort out what is causing this in the compiled clojurescript.

monolithed commented 8 years ago

Is there any reason not to implement the one?

jfkhoury commented 7 years ago

@laurentj I am trying to sniff the network for CORS requests/responses, and I can't see those responses, I'm guessing because of web-security flag that is set to true. I think this makes a good use case to implement this feature. Is there any chance this will make it to the roadmap?

Thanks.