[Edbrowse-dev] js command line access

[Edbrowse-dev] js command line access

[Karl Dahlke]

Kevin wrote me in a pm, and I hope he doesn't mind me relaying here...

I created a crude JS console within edbrowse,
for use especially on getting the DOM to work.
I noticed that javaParseExecute will accept any string,
so I hooked into twoLetter, used a letter that wasn't in
use, and brought querying of objects into the edbrowse
command line, like...

* document.childNodes.length
23
* var blah = document.getElementsByTagName("INPUT")
ok
* blah.length
25
* blah[5].name
price_range

This is damn clever!
I mean really.
I'm thinking it should be part of the real program,
not as anything we would advertise, not a feature for the public,
but like the higher levels of db, just something for us.
What do others think of this idea?

It would have to be a 2 letter or multi letter command that casual users
wouldn't stumble on by accident.  Maybe jsca for javascript comand access.
Imagine stopping in the middle of a web page and poking around the dom.
For debugging, set a variable like innerHTML and see if the side effects really happen.
Or like yesterday I had a nasty email I wanted to unsubscribe from,
cause its just marketing crap,
and I pushed the button and js stopped because something
was missing in the dom.
Imagine I went to the js console and just put an object there, or whatever,
so js would be happy and send on my unsubscribe request.
That would be cool.
This was one of those forms that can't be done without js by the way,
so for now I'm still subscribed to their shit.
anyways, do people think a backdoor to the dom would be useful for us,
assuming the public wouldn't fall through it accidentally,
and if yes then perhaps Kevin you could send me a patch,
cause it sounds like you've already done most of the work.

Karl Dahlke

Re: [Edbrowse-dev] js command line access

[Kevin Carhart]

> This is damn clever!

The idea is actually courtesy of Chris Brannon,
because we were once emailing briefly about this thing
called MozRepl.  I took it from there and found
bits of javascript on that idea.  So thank you Chris!

I know there are security issues, and you should
not allow arbitrary strings to get run as code.
I assumed this feature was too underground to mention,
or I may have mentioned it sooner.  Grin.

We could use my code for this, but the output
has not been edbrowzised or carved into lines.
I don't bring it back into an edbrowse buffer.
So the output could be a pain in the butt at
the moment, but I could give you what I have
and you could optimize it.
It also depends on what you echo.

Glad we might do this - it has certainly been
invaluable for me,
Kevin


On Fri, 25 Sep 2015, Karl Dahlke wrote:

> Kevin wrote me in a pm, and I hope he doesn't mind me relaying here...
>
> I created a crude JS console within edbrowse,
> for use especially on getting the DOM to work.
> I noticed that javaParseExecute will accept any string,
> so I hooked into twoLetter, used a letter that wasn't in
> use, and brought querying of objects into the edbrowse
> command line, like...
>
> * document.childNodes.length
> 23
> * var blah = document.getElementsByTagName("INPUT")
> ok
> * blah.length
> 25
> * blah[5].name
> price_range
>
> This is damn clever!
> I mean really.
> I'm thinking it should be part of the real program,
> not as anything we would advertise, not a feature for the public,
> but like the higher levels of db, just something for us.
> What do others think of this idea?
>
> It would have to be a 2 letter or multi letter command that casual users
> wouldn't stumble on by accident.  Maybe jsca for javascript comand access.
> Imagine stopping in the middle of a web page and poking around the dom.
> For debugging, set a variable like innerHTML and see if the side effects really happen.
> Or like yesterday I had a nasty email I wanted to unsubscribe from,
> cause its just marketing crap,
> and I pushed the button and js stopped because something
> was missing in the dom.
> Imagine I went to the js console and just put an object there, or whatever,
> so js would be happy and send on my unsubscribe request.
> That would be cool.
> This was one of those forms that can't be done without js by the way,
> so for now I'm still subscribed to their shit.
> anyways, do people think a backdoor to the dom would be useful for us,
> assuming the public wouldn't fall through it accidentally,
> and if yes then perhaps Kevin you could send me a patch,
> cause it sounds like you've already done most of the work.
>
> Karl Dahlke
> _______________________________________________
> Edbrowse-dev mailing list
> Edbrowse-dev@lists.the-brannons.com
> http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
>

--------
Kevin Carhart * 415 225 5306 * The Ten Ninety Nihilists

Re: [Edbrowse-dev] js command line access

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 1967 bytes --]

On Fri, Sep 25, 2015 at 12:55:47AM -0700, Kevin Carhart wrote:
> 
> >This is damn clever!
> 
> The idea is actually courtesy of Chris Brannon,
> because we were once emailing briefly about this thing
> called MozRepl.  I took it from there and found
> bits of javascript on that idea.  So thank you Chris!

Definitely, sounds seriously cool, I'm thinking in particular about when I
start playing with js engines etc, not to mention all the times when I wish for
an equivalent to the various developer consoles in other browsers.

> I know there are security issues, and you should
> not allow arbitrary strings to get run as code.

In this case I don't really see the security argument.
The user is typing in the js, so it's only as insecure as... say...
a shell or the like. As for the security of the site on the other end of the
connection, plenty of tools already exist (including extensions to the major
popular browsers I think) to mess with js behavior.

> I assumed this feature was too underground to mention,
> or I may have mentioned it sooner.  Grin.

Personally I'd document it. There's nothing worse than an undocumented feature
like this, that's one of the ways things fail to be maintained and security holes happen.
If it's there then not documenting it just means someone has to look at the
code, and if they're looking for exploits they'll do that anyway.

> We could use my code for this, but the output
> has not been edbrowzised or carved into lines.
> I don't bring it back into an edbrowse buffer.
> So the output could be a pain in the butt at
> the moment, but I could give you what I have
> and you could optimize it.
> It also depends on what you echo.

Fair enough, I say put it in and we'll run with it from there.

> Glad we might do this - it has certainly been
> invaluable for me,

Indeed. It also gives me some interesting ideas re:
using Edbrowse for page automation.

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Edbrowse-dev] js command line access

[Kevin Carhart]

> In this case I don't really see the security argument.

Heh heh.  Oh, in that case.. great!  I was anticipating the worst.

> If it's there then not documenting it just means someone has to look at the

Well, it isn't there, it just lives offline in my divergent, obsolete 
3.3.1.
I wrote it before youall had done the lovely JS encapsulation work.
The early pleistocene relative to today!

This was my MO for a while - I would load a page, using the
wonderful auth-cookies-http edbrowse, and then once I was in JS land,
I wasn't re-rendering, I was just echoing things to learn
about the DOM from the inside out.  I had my work cut out
for me, without completing the circle back to edbrowse.
It's the innate temptation of open 
source that you can always diverge your own hybrid at any time and fool
around instead of making patches intended for the world.
It's both good and bad, because you go off on your own cul-de-sac
and it's harder to talk to the developers because you're out of
sync.  But I learned a bunch of JS and jquery which I anticipated
could eventually be brought back to the project, especially now
that we have a node tree from tidy!!

Kevin