Re: [Perlplusplugin-developers] authorization?
Status: Beta
Brought to you by:
fholtry
From: Dmitry K. <dk...@pl...> - 2000-09-14 13:35:14
|
Hi Frank! On 13 Sep 00 at 15:02, "Frank" (Frank Holtry) wrote: Frank> If your library can avoid using the more Frank> dangerous Perl opcodes,then you could definitely use Opcode for Frank> security. I thought that just using Opcode would be enough for a good balance between security and productivity; I thought that eval itself is not a problem, while it contains a legal code. But that's rather a technical side of the implementation. My point is, that cgi authorization is only one of many ways to do things; and from my point of view it's more confusing than helpful. I think that good thing is to implement ( BTW, like Scriptics that you mentioned does) local security settings; and cgi authorization will be just an extension. Currently we have no such scheme, and the only possiblilities are either to have cgi-auth or to have none. If we agree to change this, the local-based authorization is a good thing IMHO. Frank> Another alternative I looked into and even experimented with a Frank> little is what Scriptics uses for Tcl/Tk. It's a custom Frank> interpreter embedded in the plugin that only recognizes the 'safe' Frank> subset of Tcl commands. It also handles events differently to Frank> avoid the problem of two event loops trying to maintain control Frank> simultaneously (one in Netscape, one in the plugin). You might Frank> find their approach interesting. You can get the source from Frank> http://dev.scriptics.com/software/plugin. Yes, it is really interesting, but is not applicable to perl, I think. Problems begin when plugin have to handle more than one instance of perl - in one process. When, for example, one task call _exit(), the whole plugin will die. And, the perl core itself is not thread-safe that way; moreover, such a scheme would require the existence of the event loop - but what if program doesn't have any? Of course, running all processes in one is tempting, but I see no way how to implement this model. But the worse thing is yet to come - such an integration will require the awareness of the client process, and it's IPC model. No matter, tcl or perl-tk it will be using, the code base have to be altered heavily. That doesn't matter when you're running only external windows, with no communication to the browser - but this is not interesting! I succeed integrating perl widgets into navigator window, but I want more - page and content interactions, and maybe java. I am now trying to make the plugin accepting external messages inside it's internal window event handler - so it could also handle external requests to NPN_XXX routines, which - note! - aren't thread-safe also. From the side of a perl program, its own event loop will be listening to the plugin messages, and the exact protocol should be system-specific. But that is a bad thing, because you have to hack tk's event loop code - if you need more than just an embedded widget, of course. BTW - I still can't compile the plugin under freebsd; right now my machine is busy compiling mozilla port - maybe it will work that way? -- Sincerely, Dmitry |