Re: Getting started with WebKit plugins
Re: Getting started with WebKit plugins
- Subject: Re: Getting started with WebKit plugins
- From: Christopher Drum <email@hidden>
- Date: Sat, 14 Jan 2006 10:36:15 -0800
Great tip! Thank you.
On a semi-related topic, I was wondering what kind of advice you (or
the board in general) may have for establishing security on a WebKit
plugin. Specifically, I need to ensure that my plugin is only usable
by our corporate intranet. I've been working with our web developers
toward a solution, and I believe they have some ideas that will help
the plugin verify an authenticated condition exists for the plugin to
check against. However, I would even like to go so far as to hardcode
the plugin to ONLY work at a list of very specific intranet sites.
To me it seems like the arguments passed to the plugin through
plugInViewWithArguments: contain the requesting URL, which could be
checked against a private NSArray (perhaps stored in a private
instance of some custom Security class) of "safe" intranet addresses.
However, I'm still concerned about protecting against spoofing.
What kind of security would you recommend be built into a plugin to
restrict it's use to a very specific set of conditions? It occurs to
me that a plugin could provide essential business services to a
corporate workflow, but that those same services accessible in the
wilds of the intranet would be a huge, huge, gaping security risk.
Should the plugin alone be responsible for this, or should the
intranet site's authentication get involved as well... a sort of two-
pronged approach.
I'm having a little trouble figuring out how to gain the benefits of
the potential inherent in building a custom plugin without exposing
my users to any potential negatives. In my case, the plugin's
availability is limited to a very select group of people, and it's
interface is hidden to all but three people who must have intimate
knowledge of my company's workflow and naming conventions to even
make use of the plugin. I feel this establishes fairly robust
security by default: hackers can't hack what they don't know about.
Still though, I would feel a lot better if I could very firmly and
definitively state to the project leader, "The plugin is secure
because of A, B and C."
Just curious to get other developers' thoughts on the matter.
Christopher Drum
On Jan 12, 2006, at 12:46 PM, Severin Kurpiers wrote:
Hi Christopher,
just for the case that you haven't discovered it yet: you can even
debug your plugin. Here the short description how to do this:
1. Put a link (or an alias) to the built debug version of your
plugin into ~/Library/Internet Plug-Ins.
2. Add Safari as a custom executable to your plugin project (menu
Project > New Custom Executable…)
3. Set some breakpoints.
4. Call the menu Debug > Debug Executable (or click the debug
button or use the keyboard shortcut).
It will launch Safari. You can now let Safari open a html page that
uses your plugin and the debugger will recognize the breakpoints.
It's pretty cool :)
Bye,
Severin Kurpiers
Verek Ltd.
On 11. Jan 2006, at 18:49, Christopher Drum wrote:
[...]
(10) This makes sense, and I feel silly for not thinking about the
console for the log file. For some reason it just didn't occur to
me that NSLog was sending it's text anywhere, in the context of a
plugin. Of course, it must and I thank you for reminding me of the
fact.
Christopher
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden