There is a link in my previous post, both to the sourceforge site (for official releases) and to the svn repository. However, I chose not to include a link as the new features I describe are not fully implemented/documented yet in hte "public" version (not even in the svn repository).
10:32 AM
Anonymous said...
> Crunchy can load html pages from the web (not only local ones) and perform its magic ;-)
I wrote: > Crunchy can load html pages from the web (not only local ones) and perform its magic ;-)
Anonymous wrote: Sounds dangerous! ---- You read a Python tutorial on line. You cut-and-paste the code and try it. Is it dangerous? What Crunchy does is no more, no less dangerous than this.
In a few minutes, I have adapted two "official" Python HOWTO tutorials, to include with Crunchy. The adapted version could replace, on their respective website, the original ones with no apparent change to the user loading them up in her favourite browser. However, loading them up via Crunchy, you could just execute the code by clicking a button or, in the case of examples that use the Python interpreter, type in the code in your browser window just below where the original appears, and see the result for yourself.
4:59 PM
Anonymous said...
> You read a Python tutorial on line. You cut-and-paste the code and try it. Is it dangerous? What Crunchy does is no more, no less dangerous than this.
So, what is keeping a rogue webpage from executing any Python code from the onload event handler? This code isn't running in a sandbox, is it?
So, what is keeping a rogue webpage from executing any Python code from the onload event handler? This code isn't running in a sandbox, is it? ====== No it isn't in a sandbox, and yes (with the current version), you are right that there is a potential problem.
The original design was premised on the idea that examples on the web would be loaded from "official sites", but not enough thought had been given. What will likely have to be done *for pages loaded remotely* is something like the following: 1. remove all "script" tags from the original page before it is passed to the browser; (only "script" tags added by crunchy would remain/be allowed); 2. *possibly* remove "src" attributes (which would mean that images would not be loaded); (this might not be needed with Firefox...) 3. otherwise, only retain "title" and "alt" as attributes, in addition to the styling attributes "class" and "id".
Then, 4. add in the local javascript links and css links; 5. display in the browser.
I may have to simply disable the loading remote tutorials for now, until I am more sure about the security :-(
Loading a tutorial locally should be done with the same caution as executing a local python script.
Thank you anonymous1 and anonymous2 (possibly the same person!) for raising this issue.
8:25 PM
While I knew all along it could be done, I've had a lot of fun during the last two days playing with the newest, and possibly most exciting feature of "The application formerly known as Crunchy Frog", or simply "Crunchy". It is now possible, from within a Firefox windows, to click a button and launch an external Python script. (I should mention that the bulk of this latest feature was implemented by Johannes Woolard - I just had to make a few minor changes to get it working on Windows.)
I'll provide more details later, but here's the short story. You write an html document in which you insert the Python script you want to execute inside a <pre> element with some minor markup (<pre title="external copycode">); actually, you can have as many scripts you want on any given page. Crunchy processes the page, displays the Python scripts in colour (!) and makes a copy of each available for further editing inside a <textarea>. You can then just click on a button and the script is launched.
This means that Crunchy can really transform *any* Python tutorial into an interactive experience. Crunchy can load html pages from the web (not only local ones) and perform its magic ;-)
So far, I've launched Tkinter windows, wxPython apps, Pygame programs, a terminal with a Python interpreter and, the latest, a gnuplot window that ran the gnuplot demo. You can actually have a number of independent external apps going at the same time, allowing for some interesting experiments (edit the code in the <textarea> and launch the new version).
Stay tuned for more news soon, and the announcement of the next release.
"Exciting Crunchy News"
7 Comments -
sounds cool!!
8:04 AM
A link to the project would be useful.
Does look *very* interesting.
10:11 AM
There is a link in my previous post, both to the sourceforge site (for official releases) and to the svn repository. However, I chose not to include a link as the new features I describe are not fully implemented/documented yet in hte "public" version (not even in the svn repository).
10:32 AM
> Crunchy can load html pages from the web (not only local ones) and perform its magic ;-)
Sounds dangerous!
4:45 PM
I wrote:
> Crunchy can load html pages from the web (not only local ones) and perform its magic ;-)
Anonymous wrote:
Sounds dangerous!
----
You read a Python tutorial on line. You cut-and-paste the code and try it. Is it dangerous? What Crunchy does is no more, no less dangerous than this.
In a few minutes, I have adapted two "official" Python HOWTO tutorials, to include with Crunchy. The adapted version could replace, on their respective website, the original ones with no apparent change to the user loading them up in her favourite browser. However, loading them up via Crunchy, you could just execute the code by clicking a button or, in the case of examples that use the Python interpreter, type in the code in your browser window just below where the original appears, and see the result for yourself.
4:59 PM
> You read a Python tutorial on line. You cut-and-paste the code and try it. Is it dangerous? What Crunchy does is no more, no less dangerous than this.
So, what is keeping a rogue webpage from executing any Python code from the onload event handler?
This code isn't running in a sandbox, is it?
8:03 PM
anonymous said:
So, what is keeping a rogue webpage from executing any Python code from the onload event handler?
This code isn't running in a sandbox, is it?
======
No it isn't in a sandbox, and yes (with the current version), you are right that there is a potential problem.
The original design was premised on the idea that examples on the web would be loaded from "official sites", but not enough thought had been given. What will likely have to be done *for pages loaded remotely* is something like the following:
1. remove all "script" tags from the original page before it is passed to the browser; (only "script" tags added by crunchy would remain/be allowed);
2. *possibly* remove "src" attributes (which would mean that images would not be loaded); (this might not be needed with Firefox...)
3. otherwise, only retain "title" and "alt" as attributes, in addition to the styling attributes "class" and "id".
Then,
4. add in the local javascript links and css links;
5. display in the browser.
I may have to simply disable the loading remote tutorials for now, until I am more sure about the security :-(
Loading a tutorial locally should be done with the same caution as executing a local python script.
Thank you anonymous1 and anonymous2 (possibly the same person!) for raising this issue.
8:25 PM