Re: [Perlplusplugin-developers] authorization?

[Dmitry K. <dk...@pl...>]

	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