Getting started with WebKit plugins

  • So I'm going through the Apple docs about making WebKit plugins, and
    I'm lost. The documentation in "Web Kit Plug-In Programming Topics"
    feels anemic, with many glaring omissions. For example, in going
    through the "PlugInMovieView" example project file, it seems to have
    not started it's life as a Cocoa Application. It contains no .nib
    file and no main.m (as I would expect, I think...). The documentation
    gives no indication on how to start a WebKit plugin project, nor is
    there an Xcode template to begin one (a major glaring omission,
    methinks).

    Additional, using the inspector on the target for the example project
    shows settings that would not be immediately obvious to a newbie
    plugin developer, yet the documentation makes no mention of having
    changed some of these things. Nor does the example project explain
    the alternations made to the Info.plist file for registering MIME types.

    Anyway, all of this leads to the basic question of: How does one
    start and end a plugin project? Once started, I get the gist of the
    matter, and I've successfully gotten Javascript to talk to Objective-
    C and back again through an embedded WebView in a sample Cocoa app.
    So, that part of the coding I get (for now). After the coding is
    done, what steps need to be taken to ensure the project builds out
    properly into the correct filetype. Is a plugin simply a Cocoa
    application that ends in ".plugin", or is it something more than that?

    When Safari browses a website that needs access to my new plugin,
    does the HTML for the webpage have to ask for something specific of
    the webpage, or can (for example) the Javascript in the webpage
    simply assume access to the plugin's methods are already available?
    In my test app, I simply dragged a WebView into my .nib file, had it
    load a sample .html file off my desktop and it immediately started
    using my Cocoa methods through Javascript. Will .html files in
    Safari, using my custom plugin, function likewise or does I need to
    modify the .html file in some way to let it know about the plugin's
    existence?

    Thanks in advance for any help anyone can offer on this matter.

    Christopher Drum
    http://homepage.mac.com/christopherdrum
  • Hi Christopher,

    the documentation "Web Kit Plug-in Programming Topics" isn't bad.
    Believe me, you will find most necessary information there.

    Here some thoughts that, I hope, will let you see this from a
    different perspective: a Web Kit plugin is a bundle with the
    extension "plugin". Its Info.plist requires the following entries:

    1. CFBundlePackageType has to be set to WBPL
    2. NSPrincipalClass has to be set to your NSView subclass
    3. WebPluginDescription (description)
    4. WebPluginMIMETypes (dictionary; see documentation for explanation)
    5. WebPluginName - name of your plug-in

    A plug-in is in fact an instance (a subclass) of NSView that needs to
    conform to the WebPlugIn informal protocol. Since it is just a
    subclass of NSView and not an application, it doesn't have the main-
    function, and in many cases there wont be necessary to include a nib
    file.

    I hope you've got the idea.

    Bye,

    Severin Kurpiers
    Verek Ltd.

    On 10. Jan 2006, at 09:59, <cocoa-dev-request...> wrote:

    > Message: 8
    > Date: Mon, 9 Jan 2006 20:03:32 -0800
    > From: Christopher Drum <christopherdrum...>
    > Subject: Getting started with WebKit plugins
    > To: <cocoa-dev...>
    > Message-ID: <DD3414FD-43D9-4DDC-B08E-63AC3745BCB8...>
    > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
    >
    > So I'm going through the Apple docs about making WebKit plugins, and
    > I'm lost. The documentation in "Web Kit Plug-In Programming Topics"
    > feels anemic, with many glaring omissions. For example, in going
    > through the "PlugInMovieView" example project file, it seems to have
    > not started it's life as a Cocoa Application. It contains no .nib
    > file and no main.m (as I would expect, I think...). The documentation
    > gives no indication on how to start a WebKit plugin project, nor is
    > there an Xcode template to begin one (a major glaring omission,
    > methinks).
    >
    > Additional, using the inspector on the target for the example project
    > shows settings that would not be immediately obvious to a newbie
    > plugin developer, yet the documentation makes no mention of having
    > changed some of these things. Nor does the example project explain
    > the alternations made to the Info.plist file for registering MIME
    > types.
    >
    > Anyway, all of this leads to the basic question of: How does one
    > start and end a plugin project? Once started, I get the gist of the
    > matter, and I've successfully gotten Javascript to talk to Objective-
    > C and back again through an embedded WebView in a sample Cocoa app.
    > So, that part of the coding I get (for now). After the coding is
    > done, what steps need to be taken to ensure the project builds out
    > properly into the correct filetype. Is a plugin simply a Cocoa
    > application that ends in ".plugin", or is it something more than that?
    >
    > When Safari browses a website that needs access to my new plugin,
    > does the HTML for the webpage have to ask for something specific of
    > the webpage, or can (for example) the Javascript in the webpage
    > simply assume access to the plugin's methods are already available?
    > In my test app, I simply dragged a WebView into my .nib file, had it
    > load a sample .html file off my desktop and it immediately started
    > using my Cocoa methods through Javascript. Will .html files in
    > Safari, using my custom plugin, function likewise or does I need to
    > modify the .html file in some way to let it know about the plugin's
    > existence?
    >
    > Thanks in advance for any help anyone can offer on this matter.
    >
    > Christopher Drum
    > http://homepage.mac.com/christopherdrum
    >
  • Hi Chris,

    WebKit Plugins are not Cocoa Applications -- they are plugins.  Having
    an extension as "plugin", and residing in one of the several "Internet
    Plug-ins" directory, is sufficient for Safari knowing that it is a
    plug-in.

    I've developed quite a few plug-ins using the PluginMovieView as a
    "starter kit".  The things you want to change include:

    * the extensions and mime types in the info.plist file.  These
    extensions and mime types identify the content, sent from the server,
    that your plug-in will handle.  Safari will instantiate your plug-in and
    call the methods (documented in the WebKit documentation) when it gets
    content of that type.

    * the NSPrincipalClass value in info.plist.  This should match the
    objective-C className of the WebPlugIn subclass; currently it's
    PlugInMovieView in the sample.  Once Safari loads your plug-in (because
    it matched incoming mime type to your info.plist setting), it
    instantiates an object of this type and starts calling the methods as
    described in the documentation.

    Hope this helps,
    Rudi

    -----Original Message-----
    From: cocoa-dev-bounces+rsherry=<adobe.com...>
    [mailto:cocoa-dev-
    Date: Mon, 9 Jan 2006 20:03:32 -0800
    From: Christopher Drum <christopherdrum...>
    Subject: Getting started with WebKit plugins
    To: <cocoa-dev...>

    So I'm going through the Apple docs about making WebKit plugins, and
    I'm lost. The documentation in "Web Kit Plug-In Programming Topics"
    feels anemic, with many glaring omissions. For example, in going
    through the "PlugInMovieView" example project file, it seems to have
    not started it's life as a Cocoa Application. It contains no .nib
    file and no main.m (as I would expect, I think...). The documentation
    gives no indication on how to start a WebKit plugin project, nor is
    there an Xcode template to begin one (a major glaring omission,
    methinks).

    Additional, using the inspector on the target for the example project
    shows settings that would not be immediately obvious to a newbie
    plugin developer, yet the documentation makes no mention of having
    changed some of these things. Nor does the example project explain
    the alternations made to the Info.plist file for registering MIME types.

    Anyway, all of this leads to the basic question of: How does one
    start and end a plugin project? Once started, I get the gist of the
    matter, and I've successfully gotten Javascript to talk to Objective-
    C and back again through an embedded WebView in a sample Cocoa app.
    So, that part of the coding I get (for now). After the coding is
    done, what steps need to be taken to ensure the project builds out
    properly into the correct filetype. Is a plugin simply a Cocoa
    application that ends in ".plugin", or is it something more than that?

    When Safari browses a website that needs access to my new plugin,
    does the HTML for the webpage have to ask for something specific of
    the webpage, or can (for example) the Javascript in the webpage
    simply assume access to the plugin's methods are already available?
    In my test app, I simply dragged a WebView into my .nib file, had it
    load a sample .html file off my desktop and it immediately started
    using my Cocoa methods through Javascript. Will .html files in
    Safari, using my custom plugin, function likewise or does I need to
    modify the .html file in some way to let it know about the plugin's
    existence?

    Thanks in advance for any help anyone can offer on this matter.

    Christopher Drum
    http://homepage.mac.com/christopherdrum

    ------------------------------

    Message: 9
    Date: Mon, 09 Jan 2006 20:11:22 -0800
    From: "Martin" <martin...>
    Subject: Re: Crash in _blinkCaretTimerAction (NSTextView)
    To: "Douglas Davidson" <ddavidso...>
    Cc: <cocoa-dev...>
    Message-ID: <7D619.14B16.1F916D.Nisus.ID...>
    Content-Type: text/plain; charset="UTF-8"

    Douglas,

    >> Is there anything more specific I might need to know? For instance,
    which
    >> text view is responsible for the invalidation?
    >
    > Actually, to be more specific, the timer is invalidated when the
    > NSTextViewSharedData is deallocated, which happens when all of the
    text
    > views for a given layout manager have been deallocated.

    I've continued debugging with this new information, but I still don't
    see what could be going wrong. I've posedAs NSTextViewSharedData and
    overridden _fixSharedData to view the sequence of events. Here is what I
    see:

    I. The NSLayoutManager deallocates and releases all of its
    NSTextContainers.
    A. Each NSTextContainer deallocates.
      1. The container nils the container on its NSTextView.
      a. The NSTextView autoreleases its original
    shared data (call it "A").
      b. A new shared data instance (call it "B") is
    assigned to the NSTextView.
      2. The container releases its NSTextView causing it to
    deallocate.
      a. The new shared data "B" is released and
    deallocates.
    II. An autorelease pool is popped and the original shared data "A" is
    deallocated.
    III. Timer fires.
    B. _blinkCaretTimerAction tries to access an NSTextView
    deallocated in step 2 above.

    If I understand this interaction correctly, the timers should all be
    invalid. The original shared data for the NSLayoutManager is deallocated
    in step II, while each temporary shared data is deallocated ASAP in step
    2.a.

    Is there any other line of investigation that you think I should follow?
    Thanks again,

    ~Martin

    ------------------------------

    Message: 10
    Date: Mon, 09 Jan 2006 22:56:03 -0800
    From: Greg Herlihy <greghe...>
    Subject: Re: Checkbox, Dictionary, Bindings
    To: Chris Outwin <coutwin...>, <cocoa-dev...>
    Message-ID: <BFE89A83.5A52%<greghe...>
    Content-Type: text/plain;    charset="US-ASCII"

    NSNumbers may be immutable, but they are not irreplaceable.

    To check or uncheck the checkbox simply replace the NSNumber currently
    representing its checked state with a different NSNumber whose value
    represents the checkbox's updated state.

    Greg

    On 1/9/06 3:18 PM, "Chris Outwin" <coutwin...> wrote:

    > I would like to manage a checkbox via a dictionary and bindings.  The
    > problem is NSNumber and NSValue are immutable, and I can't find
    > another class to represent the changing on/off state of the
    > checkbox.  What class can I use?
    >
    > NSDictionary* _properties;
    >
    > NSArray* values = [NSArray arrayWithObjects:[What Class?],  //
    > scalesImage
    > nil];
    >
    > NSArray* keys = [NSArray arrayWithObjects:@"scalesImage"
    >
    > _properties = [[NSDictionary alloc] initWithObjects:values
    > forKeys:keys];
    > _______________________________________________
    > Do not post admin requests to the list. They will be ignored.
    > Cocoa-dev mailing list      (<Cocoa-dev...>)
    > Help/Unsubscribe/Update your Subscription:
    > http://lists.apple.com/mailman/options/cocoa-dev/<greghe...>
    >
    > This email sent to <greghe...>

    ------------------------------

    Message: 11
    Date: Mon, 9 Jan 2006 23:24:09 -0800 (PST)
    From: Jordan Evans <xcoder66...>
    Subject: Re: Radix Class
    To: <cocoa-dev...>
    Message-ID: <20060110072409.872.qmail...>
    Content-Type: text/plain; charset=iso-8859-1

    --- Alberto Ricart <alberto_ricart...> wrote:

    > 1) It is very weird to see struct's used in OO.
    > You should create another object to represent your
    > RadixSet. If you
    > make the instance variables public, then from within
    > your code you
    > can do foo->something to access them. True OO would
    > not do this (as
    > you are breaking encapsulation), and would instead
    > call accessor
    > methods. Unless you are writing high-performance
    > code that requires
    > the optimization.

    I made the struct so the class was more stand alone.
    One benefit is the loss of overhead through messaging.
    But I"m not sure if this is really happened. I
    haven'd done a performance test.  I'll definitely set
    one of up in the near future.

    > 2) It seems that you are caching values like the
    > count  (numOfSets)
    > that are managed (or should be managed in a
    > collection, so you don't
    > keep track of that kind of stuff, as the collection
    > would do it for
    > you). I would rewrite to use the collections more
    > fully.

    I wrote it that way at first, but I found using a
    value returned from a message as a condition in a loop
    created unneccessary message overhead.  Each time the
    loop increments the message is called just to get a
    value that could be cached.

    > 3) #2 is even stronger when you realize that you are
    > given an array
    > (so you use a collection to pass them around, but
    > then revert to
    > unroll it into your own data structure. Why?

    I'm not sure I see unrolling of data, except in the
    case of the struct being assinged values that are
    queried form NSArrays.  Again, those values I think
    are better cached rather than messaged each time.  The
    element is my struct is just a highlighted object in
    an NSArray, but NSArray has no function to mark a
    given object, so element provides a service in the
    struct, NSArray can't provide.  I'd like to think of
    these structs used as a data extension of NSArray,
    although some data is mere cached copies.

    > 4) You would probably never reInitWithXXX, instead
    > you simply alloc
    > and init a new Radix. If you are doing object
    > pooling, then the
    > correct thing to do is to have a setter method like
    > setArrayOfSets:
    > (NSArray*) to assign a new collection to your
    > object.

    I thought about this.  I was thinking in terms of
    immutabiity and mutability and couldn't classify Radix
    that way.  I sure wish something would break through
    that would make me see it.  I put in -reInitWith: in
    the case when the old source initialized in Radix was
    no longer neccessary, but a new source needed Radix's
    special abilities.

    The old source isn't owned by Radix, rather it has an
    aquaintance with no memory ties (just data
    connections).  If the aquaintance is neccessary, and a
    new source comes on to the scene, it's more than an
    aquaitance and it's aquaintance should not be ended
    with reInitWith.  In the case of a strong aquaintance,
    a new Radix should then be created.

    I'm not sure what pooling means in the context you
    used it, so I can't comment.

    > 5) zeroElements would be clear or something like
    > this. If you
    > delegate the set management to an NSArray, you
    > simply remove all
    > objects and be done, this would also remove many of
    > the malloc/frees

    I'm not so sure this would be optimal for this class
    that may need to perform very quickly as sensitive
    times, but I may have misinterpreted what you have
    meant.

    I'm new to this, so please point out where I may have
    gone wrong.

    Thanks for your input Alberto.


    __________________________________________
    Yahoo! DSL - Something to write home about.
    Just $16.99/mo. or less.
    dsl.yahoo.com

    ------------------------------

    Message: 12
    Date: Tue, 10 Jan 2006 20:31:30 +1300
    From: David Wilson <dgwilson...>
    Subject: Re: Screen saver with a configure sheet?
    To: patrick <gibblertron...>
    Cc: cocoadev <cocoa-dev...>
    Message-ID: <29719659-32F0-4D00-8605-35E50EBB98EB...>
    Content-Type: text/plain;    charset=US-ASCII;    delsp=yes;
    format=flowed

    Hi Patrick...

    My Screen Saver (see http://www.versiontracker.com/dyn/moreinfo/
    macosx/26020 ) has the code implemented as below.
    It's a big configure sheet for a screen saver...

    Hope this helps. Feel free to contact me and I'll try to be of more
    assistance.

    - David

    - (BOOL)hasConfigureSheet
    {
        return YES;
    }

    - (NSWindow*)configureSheet
    {
        if (configureSheet == nil)
            [NSBundle loadNibNamed:@"ConfigureSheet.nib" owner:self];

    configW = configureSheet;
    return configW;
    }

    - (IBAction)closeSheetOK:(id)sender
    {
    //text deleted. Add code here if you need special handling after
    the
    sheet closes


    // close sheet
        [NSApp endSheet:configureSheet];
    return;
    }

    On 10/01/2006, at 11:44 AM, patrick wrote:

    > I'm making a screen saver with a configure sheet, and I'm having
    > trouble understanding how I can create a connection between the sheet
    > and my screen saver class.
    >
    > In my screen saver's header file, I have:
    >
    > IBOutlet id *configureSheet;
    >
    > I've created a NIB with the panel, but since the ScreenSaverEngine
    > creates the instance of my screen saver view, it doesn't seem like I
    > would create an instance of the screen saver view in my NIB.
    >
    > The only tutorial I could find about making a screen saver with a
    > configure sheet didn't explain this part, and just provided a NIB that
    > somehow already has the connection in it.
    >
    > Any pointers would be greatly appreciated.
    >
    > Thanks,
    >
    > Patrick
    > _______________________________________________
    > Do not post admin requests to the list. They will be ignored.
    > Cocoa-dev mailing list      (<Cocoa-dev...>)
    > Help/Unsubscribe/Update your Subscription:
    > http://lists.apple.com/mailman/options/cocoa-dev/dgwilson%
    > 40paradise.net.nz
    >
    > This email sent to <dgwilson...>
    >

    ------------------------------

    Message: 13
    Date: Tue, 10 Jan 2006 02:02:24 -0600
    From: Daniel Griffin <danielg...>
    Subject: creating custom widgets(?)
    To: <cocoa-dev...>
    Message-ID: <D94B4310-4D74-469E-828A-AF0E5C9BD37D...>
    Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

    Hi all,
    First time poster, short time reader. To start with I am not
    sure if
    I am using the right terminology. I am attempting to create a button
    that contains 2 images and some text for a simple instant messenger.
    I am not sure how I should go about this. I am new to cocoa and new
    to gui's overall. Do i subclass NSView? subclass something else? Is
    there a way to add what I want to NSButton? I have looked but I dont
    know if I am looking in the right place.

    Thank you in advance
    Daniel Griffin

    ------------------------------

    Message: 14
    Date: Tue, 10 Jan 2006 00:02:23 -0800
    From: "Frederick C. Lee" <fclee...>
    Subject: Unable to Load Window NIB
    To: Cocoa Developers <cocoa-dev...>
    Message-ID: <E658BA18-EB82-4A29-8CBA-4E8338788696...>
    Content-Type: text/plain;    charset=US-ASCII;    delsp=yes;
    format=flowed

    Does anyone know why I can't load a NIB file?
    The MainMenu.nib loads without hassle.

    I've been loading NSWindowControllers  in other projects but this one
    escapes me.

    Ric.

    Running XCode 2.2
                      IB for OS X 10.2+

    Runtime Error:
    2006-01-09 23:44:12.229 Global Village[883] -[GVWindowController
    loadWindow]: failed to load window nib file 'GVWindowController'.

    Inside AppDelegate:

    ...
    - (IBAction)loadGVWindowController:(id)sender {
        NSLog(@"{loadGVWindowController}");
        if (!gvWindowController) {
            [self setGVWindowController:[[GVWindowController alloc] init]];
            [[self gvWindowController] showWindow:self];
        }
    }
    ...
    -------------------------------------------------------------

    @interface GVWindowController : NSWindowController {
    ...
    }
    ...

    @implementation GVWindowController

    #pragma mark Initialization

    - (id)init {
        return [super initWithWindowNibName:@"GVWindowController"];
    }

    //
    ------------------------------------------------------------------------

    ---------------------------------

    - (void)awakeFromNib {
        [[self window] center];
        [[self window] makeKeyWindow];
    }
    ...

    ------------------------------

    Message: 15
    Date: Tue, 10 Jan 2006 03:33:47 -0500
    From: Cameron Hayne <hayne...>
    Subject: Re: Crash in _blinkCaretTimerAction (NSTextView)
    To: Martin <martin...>
    Cc: CocoaDev list <cocoa-dev...>
    Message-ID: <F2EB599E-B761-4168-8094-272FE29A848B...>
    Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

    On 9-Jan-06, at 11:11 PM, Martin wrote:

    > If I understand this interaction correctly, the timers should all
    > be invalid

    You could perhaps check in the debugger if the timers are in fact
    invalid (via the  'isValid' method)

    --
    Cameron Hayne
    <hayne...>

    ------------------------------

    Message: 16
    Date: Tue, 10 Jan 2006 09:55:55 +0100
    From: Damien Bobillot <damien.bobillot.2002+<applelist...>
    Subject: Re: Guarding against missing ObjC implementation
    To: Daniel Jalkut <jalkut...>
    Cc: Cocoa-Dev List <cocoa-dev...>
    Message-ID: <0C40A081-8803-4299-B263-0412EAF8A447...>
    Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

    Daniel Jalkut wrote :

    > One of the nicest features and worst pitfalls of Objective-C
    > programming is the dynamic messaging nature of the language.
    >
    > In the "pitfall" category is a problem I run into from time to time
    > where a project possesses the required header file for a particular
    > category, but somehow the source file corresponding to that header
    > has been omitted from the project.
    >
    > When this happens, the compile triggers no warning: you don't get
    > "incomplete class" warnings when a category's methods are not
    > fulfilled at compile/link time.
    >
    > I'd like to guard against this problem biting me in the future, and
    > I'd like your feedback. What is the best approach?

    The approach I personally use is to create a protocol describing what
    methods must be implemented for a given functionality :

    @protocol MyProto
    - (void) revealInFinder;
    - (void) openFileInFinder;
    @end

    Then, you may check if an object implementes all methods of this
    protocol :

    id object;
    if([object conformsToProtocol:@protocol(MyProto)]) {
    ...

    --
    Damien Bobillot

    > One approach would be to add unit tests for every category. I put
    > something like this in one of my test suites as a practical
    > experiment:
    >
    > ------------------------
    > #define RequireClassMethod(myClass, mySel) \
    > do { \
    > NSString* description = [NSString
    stringWithFormat:@"Check for %@
    > in %@", NSStringFromSelector(mySel), NSStringFromClass([myClass
    > class])]; \
    > STAssertTrue([myClass instancesRespondToSelector:mySel],

    > description); \
    > } while (0)
    >
    > - (void) testRequiredMethodsPresence
    > {
    > // NSString+FileUtils
    > RequireClassMethod(NSString, @selector(revealInFinder));
    > RequireClassMethod(NSString, @selector(openFileInFinder));
    > }
    > ------------------------
    >
    > This does the trick, but adding explicit tests for every method
    > implemented by a category seems overly laborious.

    ------------------------------

    Message: 17
    Date: Tue, 10 Jan 2006 09:59:47 +0100
    From: j o a r <joar...>
    Subject: Re: Unable to Load Window NIB
    To: "Frederick C. Lee" <fclee...>
    Cc: Cocoa Developers <cocoa-dev...>
    Message-ID: <927B19B4-02B2-4228-A2DA-9D5C5ED0D5D8...>
    Content-Type: text/plain; charset="us-ascii"

    On 10 jan 2006, at 09.02, Frederick C. Lee wrote:

    > Does anyone know why I can't load a NIB file?
    > The MainMenu.nib loads without hassle.
    > I've been loading NSWindowControllers  in other projects but this
    > one escapes me.

    Have you verified that the nib file is being copied over to the built
    application?

    > if (!gvWindowController) {
    > [self setGVWindowController:[[GVWindowController alloc]
    > init]];

    This seems like a potential memory leak. It is the responsibility of
    the setter method to retain it's argument, and you should therefore
    pass the object autoreleased.

    j o a r

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: smime.p7s
    Type: application/pkcs7-signature
    Size: 2380 bytes
    Desc: not available
    Url :
    http://lists.apple.com/pipermail/cocoa-dev/attachments/20060110/fa7f0faf
    /smime.bin

    ------------------------------

    _______________________________________________
    Cocoa-dev mailing list
    <Cocoa-dev...>
    http://lists.apple.com/mailman/listinfo/cocoa-dev

    End of Cocoa-dev Digest, Vol 3, Issue 41
    ****************************************
  • Many thanks to Severin and Rudi who wrote with help on my struggle to
    understand WebKit plugins. I got my plugin to work like a champ. As
    documentation for future research (because I'm sure I'll forget
    something, and I'll probably search the lists for the answer again),
    here's what I did.

    1. Create a new project in Xcode under New Project > Bundle > Cocoa
    Bundle.

    2. To the project's Classes folder I added a new file, choosing the
    template for Objective-C NSView subclass

    3. I changed the Info.plist file as recommended by Severin and Rudi.
            a. CFBundlePackageType set to WBPL
            b. NSPrincipalClass set to match the name of the new NSView
    subclass I created in step 2.
            c. WebPluginDescription set to something readable that makes
    sense for the project
            d. WebPluginMIMETypes - This part confused me as a MIME
    newbie. I see now that this is where you register what types of file
    extension calls in the webpage will trigger the use of the custom
    plugin. I created my own custom MIME type that will only be used
    internally with a corresponding custom extension to represent that
    "filetype". The key to my understanding this was Rudi's point that
    Safari loads my plugin because it "matched an incoming MIME type to
    my Info.plist setting".
            e. WebPluginName again set to something readable that makes
    sense for the project

    4. In mimicking how the Apple samples work, I created an instance
    variable of type NSDictionary named *arguments to hold the arguments
    passed to the class by the web browser, and a corresponding
    setArguments: method.

    5. Implemented the one method that is 100% necessary for WebKit
    plugins to work
        +(NSView *)plugInViewWithArguments:(NSDictionary *)arguments;

    6. Implemented the methods I want my plugin to call.

    7. Implemented an optional method (which, upon reading the docs more
    closely, isn't necessary for my simple test plugin which only has two
    methods and I want both exposed anyway)
            + (BOOL)isSelectorExcludedFromWebScript:(SEL)aSelector

    8. Implemented -(id)objectForWebScript, returning self

    Now, I've only ever sudied C++ and Objective-C / Cocoa (with a teeny
    bit of Java and HTML thrown in). Not understanding how the HTML and
    Javascript trigger WebKit plugins and obtain an instance of my
    plugin's class was a big mystery to me.

    8. Following Apple's sample code, I put an <embed> whose type is of
    the same custom MIME type I created in step 2d and whose source (src)
    references a nonexistent file with an extension that matches the one
    I created in step 2d. This allowed me to simply trigger the plugin to
    verify something was happening.

    9. Using JavaScript's document.embeds[0] command, I was able to
    obtain the instance of my plugin. With that in hand, calling the
    Javascript-accessible functions was simplicity itself, using dot
    notation and underscores (in place of Obj-C colons). I understand now
    that I could make the methods I exposed more friendly to use by
    implementing webScriptNameForSelector: in my NSView subclass.

    10. Finally, I found it useful to know if something was happening,
    say on plugin initialization or any other method that didn't do
    something obvious. I put NSAlert calls in each method so I could get
    visible confirmation that the plugin loaded and such. At one point I
    found that the plugin was initializing, but nothing further happened.
    The NSAlerts helped me track down a bug in my HTML file that wasn't
    utilizing the plugin properly.

    Thanks again for everyone's help! The explanations helped me make
    sense of what I was reading in the Apple docs, and it's all much
    clearer to me now.

    Christopher Drum
    http://homepage.mac.com/christopherdrum
  • Glad that we could be of help.  I have a few other suggestions:

    (7) You do need + (BOOL)isSelectorExcludedFromWebScript:(SEL)
    aSelector, and should use it.  Your object is a subclass of NSView,
    remember, so any NSView method is also exposed unless you
    specifically exclude it (and so are all the methods of all the
    objects to which NSView is a subclass, etc).  I recently went through
    a Security Audit of my code so I'm particularly sensitive to white-
    list  / black-list issues ;)

    (9) You can also give the embed a name (I forget whether it's "name="
    or "id="), and then do document.embeds['objectname'].  This way, if
    your code is put into a page with more than one embed, you won't have
    to remember to adjust the index, as long as you have a unique name.

    (10) NSLog, the Cocoa equivalent of printf, is also a handy tool for
    watching things going on, and then it doesn't interfere with the
    workings by putting up alerts.  These go to the console.

    -- Rudi

    On Jan 10, 2006, at 10:02 PM, Christopher Drum wrote:

    > Many thanks to Severin and Rudi who wrote with help on my struggle
    > to understand WebKit plugins. I got my plugin to work like a champ.
    > As documentation for future research (because I'm sure I'll forget
    > something, and I'll probably search the lists for the answer
    > again), here's what I did.
    >
    > 1. Create a new project in Xcode under New Project > Bundle > Cocoa
    > Bundle.
    >
    > 2. To the project's Classes folder I added a new file, choosing the
    > template for Objective-C NSView subclass
    >
    > 3. I changed the Info.plist file as recommended by Severin and Rudi.
    > a. CFBundlePackageType set to WBPL
    > b. NSPrincipalClass set to match the name of the new NSView
    > subclass I created in step 2.
    > c. WebPluginDescription set to something readable that
    > makes sense for the project
    > d. WebPluginMIMETypes - This part confused me as a MIME
    > newbie. I see now that this is where you register what types of
    > file extension calls in the webpage will trigger the use of the
    > custom plugin. I created my own custom MIME type that will only be
    > used internally with a corresponding custom extension to represent
    > that "filetype". The key to my understanding this was Rudi's point
    > that Safari loads my plugin because it "matched an incoming MIME
    > type to my Info.plist setting".
    > e. WebPluginName again set to something readable that makes
    > sense for the project
    >
    > 4. In mimicking how the Apple samples work, I created an instance
    > variable of type NSDictionary named *arguments to hold the
    > arguments passed to the class by the web browser, and a
    > corresponding setArguments: method.
    >
    > 5. Implemented the one method that is 100% necessary for WebKit
    > plugins to work
    > +(NSView *)plugInViewWithArguments:(NSDictionary *)arguments;
    >
    > 6. Implemented the methods I want my plugin to call.
    >
    > 7. Implemented an optional method (which, upon reading the docs
    > more closely, isn't necessary for my simple test plugin which only
    > has two methods and I want both exposed anyway)
    > + (BOOL)isSelectorExcludedFromWebScript:(SEL)aSelector
    >
    > 8. Implemented -(id)objectForWebScript, returning self
    >
    > Now, I've only ever sudied C++ and Objective-C / Cocoa (with a
    > teeny bit of Java and HTML thrown in). Not understanding how the
    > HTML and Javascript trigger WebKit plugins and obtain an instance
    > of my plugin's class was a big mystery to me.
    >
    > 8. Following Apple's sample code, I put an <embed> whose type is of
    > the same custom MIME type I created in step 2d and whose source
    > (src) references a nonexistent file with an extension that matches
    > the one I created in step 2d. This allowed me to simply trigger the
    > plugin to verify something was happening.
    >
    > 9. Using JavaScript's document.embeds[0] command, I was able to
    > obtain the instance of my plugin. With that in hand, calling the
    > Javascript-accessible functions was simplicity itself, using dot
    > notation and underscores (in place of Obj-C colons). I understand
    > now that I could make the methods I exposed more friendly to use by
    > implementing webScriptNameForSelector: in my NSView subclass.
    >
    > 10. Finally, I found it useful to know if something was happening,
    > say on plugin initialization or any other method that didn't do
    > something obvious. I put NSAlert calls in each method so I could
    > get visible confirmation that the plugin loaded and such. At one
    > point I found that the plugin was initializing, but nothing further
    > happened. The NSAlerts helped me track down a bug in my HTML file
    > that wasn't utilizing the plugin properly.
    >
    > Thanks again for everyone's help! The explanations helped me make
    > sense of what I was reading in the Apple docs, and it's all much
    > clearer to me now.
    >
    > Christopher Drum
    > http://homepage.mac.com/christopherdrum
    >
  • Thank you for the suggestions.

    (7) Yes, I just discovered today (after breaking my plugin) that I
    need + (BOOL)isSelectorExcludedFromWebScript:(SEL)aSelector. Thank you.

    (9) I also just discovered the embed name last night (as I started
    familiarizing myself with Javascript more). Thank you for that as
    well. The syntax is "name=".

    (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

    On Jan 11, 2006, at 9:12 AM, Rudi Sherry wrote:

    > Glad that we could be of help.  I have a few other suggestions:
    >
    > (7) You do need + (BOOL)isSelectorExcludedFromWebScript:(SEL)
    > aSelector, and should use it.  Your object is a subclass of NSView,
    > remember, so any NSView method is also exposed unless you
    > specifically exclude it (and so are all the methods of all the
    > objects to which NSView is a subclass, etc).  I recently went
    > through a Security Audit of my code so I'm particularly sensitive
    > to white-list  / black-list issues ;)
    >
    > (9) You can also give the embed a name (I forget whether it's
    > "name=" or "id="), and then do document.embeds['objectname'].  This
    > way, if your code is put into a page with more than one embed, you
    > won't have to remember to adjust the index, as long as you have a
    > unique name.
    >
    > (10) NSLog, the Cocoa equivalent of printf, is also a handy tool
    > for watching things going on, and then it doesn't interfere with
    > the workings by putting up alerts.  These go to the console.
    >
    > -- Rudi
    >
    > On Jan 10, 2006, at 10:02 PM, Christopher Drum wrote:
    >
    >> Many thanks to Severin and Rudi who wrote with help on my struggle
    >> to understand WebKit plugins. I got my plugin to work like a
    >> champ. As documentation for future research (because I'm sure I'll
    >> forget something, and I'll probably search the lists for the
    >> answer again), here's what I did.
    >>
    >> 1. Create a new project in Xcode under New Project > Bundle >
    >> Cocoa Bundle.
    >>
    >> 2. To the project's Classes folder I added a new file, choosing
    >> the template for Objective-C NSView subclass
    >>
    >> 3. I changed the Info.plist file as recommended by Severin and Rudi.
    >> a. CFBundlePackageType set to WBPL
    >> b. NSPrincipalClass set to match the name of the new
    >> NSView subclass I created in step 2.
    >> c. WebPluginDescription set to something readable that
    >> makes sense for the project
    >> d. WebPluginMIMETypes - This part confused me as a MIME
    >> newbie. I see now that this is where you register what types of
    >> file extension calls in the webpage will trigger the use of the
    >> custom plugin. I created my own custom MIME type that will only be
    >> used internally with a corresponding custom extension to represent
    >> that "filetype". The key to my understanding this was Rudi's point
    >> that Safari loads my plugin because it "matched an incoming MIME
    >> type to my Info.plist setting".
    >> e. WebPluginName again set to something readable that
    >> makes sense for the project
    >>
    >> 4. In mimicking how the Apple samples work, I created an instance
    >> variable of type NSDictionary named *arguments to hold the
    >> arguments passed to the class by the web browser, and a
    >> corresponding setArguments: method.
    >>
    >> 5. Implemented the one method that is 100% necessary for WebKit
    >> plugins to work
    >> +(NSView *)plugInViewWithArguments:(NSDictionary *)arguments;
    >>
    >> 6. Implemented the methods I want my plugin to call.
    >>
    >> 7. Implemented an optional method (which, upon reading the docs
    >> more closely, isn't necessary for my simple test plugin which only
    >> has two methods and I want both exposed anyway)
    >> + (BOOL)isSelectorExcludedFromWebScript:(SEL)aSelector
    >>
    >> 8. Implemented -(id)objectForWebScript, returning self
    >>
    >> Now, I've only ever sudied C++ and Objective-C / Cocoa (with a
    >> teeny bit of Java and HTML thrown in). Not understanding how the
    >> HTML and Javascript trigger WebKit plugins and obtain an instance
    >> of my plugin's class was a big mystery to me.
    >>
    >> 8. Following Apple's sample code, I put an <embed> whose type is
    >> of the same custom MIME type I created in step 2d and whose source
    >> (src) references a nonexistent file with an extension that matches
    >> the one I created in step 2d. This allowed me to simply trigger
    >> the plugin to verify something was happening.
    >>
    >> 9. Using JavaScript's document.embeds[0] command, I was able to
    >> obtain the instance of my plugin. With that in hand, calling the
    >> Javascript-accessible functions was simplicity itself, using dot
    >> notation and underscores (in place of Obj-C colons). I understand
    >> now that I could make the methods I exposed more friendly to use
    >> by implementing webScriptNameForSelector: in my NSView subclass.
    >>
    >> 10. Finally, I found it useful to know if something was happening,
    >> say on plugin initialization or any other method that didn't do
    >> something obvious. I put NSAlert calls in each method so I could
    >> get visible confirmation that the plugin loaded and such. At one
    >> point I found that the plugin was initializing, but nothing
    >> further happened. The NSAlerts helped me track down a bug in my
    >> HTML file that wasn't utilizing the plugin properly.
    >>
    >> Thanks again for everyone's help! The explanations helped me make
    >> sense of what I was reading in the Apple docs, and it's all much
    >> clearer to me now.
    >>
    >> Christopher Drum
    >> http://homepage.mac.com/christopherdrum
    >>
    >
  • 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
  • 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
    >>
    >
    >
  • On Jan 14, 2006, at 10:36 AM, Christopher Drum wrote:

    > 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.

    What would a user gain by spoofing to make your plug-in is talking to
    a server that isn't one of the corporate servers?  That is, is there
    confidential information being passed from the client's machine to
    the server, or only the other way around?  The answer to that
    question will greatly affect which security measures you want.

    If this plug-in is only to access corporate information, then you
    don't have to worry about spoofing the servers because the hackers
    won't gain anything by having your plug-in talking to fake servers.
    All they're get is fake information...

    That said, whitelists are in general considered more secure than
    blacklists.  Unfortunately, a hacker could tamper with your plug-in
    to add URLs to the whitelist.

    > 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.

    As well you should.  A savvy and determined hacker that gets a copy
    of your plug-in will fairly easily be able to find out the URLs it's
    checking against, or spoof trusted sites.

    > 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.

    What exactly do you mean by "the wilds of the intranet"?  Do outside
    users have access to that intranet?

    The other thing to worry about is whether the corporate servers need
    to verify that they're talking to your plug-in: suppose someone wrote
    another plug-in so the corporate server thought it was talking to
    your plug-in when it was actually talking to a hacker's plug-in?

    To have your plug-in verify that it was really talking to the right
    server, you could also use a public/private key: there are any number
    of encryption verification handshakes.  Unfortunately that won't work
    the other way around, since you would then have to have the private
    key stored in the plug-in itself, and reverse-engineering would
    reveal that.

    The best you can do is have the server know it's talking to a
    qualified user by having usernames and passwords.  Force the user to
    log in, and have the server not respond with any information unless
    every request contains the resultant cookie (or whatever token the
    server provides).

    The user/password scheme is still vulnerable to man-in-the-middle
    attacks; use https connections to the server (even on the intranet)
    to mitigate that.  Even those are hackable.... it depends on how
    valuable this information is.

    > 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.

    I'm not a big fan of "security by obscurity"; a disgruntled ex-
    employee would have and could share that knowledge.  Usernames/
    passwords are always good.

    > 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."

    Really what you're looking for is to show that anyone that gets by
    the plug-in security already must have enough ability and knowledge
    to hack the system without it; that is "the plug-in is not the
    weakest point of attach because of A, B and C".

    Hope this helps,
    Rudi

    > 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
    >>>
    >>
    >>
    >
  • I think it unlikely that a browser plug-in could be measurably more secure
    than its browser. I certainly would not write a browser plug-in with that
    expectation. But the browser already provides a lot of security-related
    services; so the plug-in should avail itself of those in order to protect
    private information and to prevent spoofing, for example.

    More specifically, to eliminate the risk of connecting to a "decoy" web
    site, the browser should connect to the server via SSL (https). SSL
    authenticates the server while encrypting the message traffic to prevent
    third-party eavesdropping.

    On 1/14/06 10:36 AM, "Christopher Drum" <christopherdrum...> wrote:

    > 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.

    I would look at the inverse though: if this measure really would improve
    security - than the conclusion to draw would be that unless the plug-in's
    communications are tightly controlled, there is a real chance of a security
    lapse - and I would find that conclusion more disturbing than the whatever
    reassurance I would take from the proposed fix.

    > 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.

    Again any user should use SSL if spoofing is a concern. And presumably would
    already be doing so since these issues are not plug-in specific. And in
    fact, the farther one gets away from the plug-in: its code and the logic of
    its data processing - and the more one tries to control external factors,
    such as which web sites the plug-in works with or when, the less effective
    such measures ultimately become. Such steps are in a way shielding
    weaknesses rather than building security from the inside out.

    > 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.

    Establishing the authenticity of the data should be require examining only
    the data itself, and not have to rely on external factors, such as the means
    by which the data was delivered (though obviously it could be a criterion).
    In some ways restricting the plug-in to specific sites makes it less secure,
    because it doesn't fix the core problem which is that the plug-in apparently
    cannot tell good data from bad.

    If there is such a security risk were the plug-in to "fall into the wrong
    hands" so to speak, it would seem to me that the fix would not to do
    everything to keep it out of those hands, but for the plug-in to be more
    discerning about whose hands it is in and why. The difference between the
    two approaches is that one can be accomplished in software, and the other
    cannot.

    > 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."

    There is no security in obscurity. If the plug-in's security rests on the
    assumption that no one will ever "find out about it", then its security is
    tied to happenstance and not to anything in the code. Security begins and
    ends with the software. And while other steps can be taken to supplement a
    piece of software's intrinsic security, they can never compensate for a
    security hole in the software. If a program is not inherently secure, it is
    simply not secure.

    Greg
previous month january 2006 next month
MTWTFSS
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
Go to today