Re: State of Digibug module

Tim Almdal wrote:
> Here's what's left:
>
>    1. "we only need to use the proxy for photos where you don't have
>       view_full privs"
 >
>       I think its risky to do that.  I'd prefer to leave the proxy for
>       everything.  One its less code (don't have to check about
>       permissions). Ok, its only a couple of lines.  Secondly, there is
>       a time delay between order placement and order fulfillment
>       permissions could have been removed.

Yes, but then you're also overloading the proxy table which might
require you to have a task to do cleanup, etc.  If you use the public
url, there are less moving parts for most operations because the remote
server is just dealing with publicly available files.  Removing
permissions during the time delay is an extreme edge case here.  The
time delay is going to approach zero in most cases.

>    2. "there's no security in print_photo() -- I can use it to get access
>       to full size photos even if I can't view them"
 >
>       I guess, if you know the url you can, I'm open to suggestions
>       regarding closing that hole.  In some cases that is point of this.
>       On my gallery I will probably remove view fullsize from every one
>       but allow them to print it which requires access to the fullsize
>       behind the scenes.

Digibug_Controller::print_photo() takes an item id and creates a proxy
url for it, then returns the proxy form.  This means that I can go to
your website, guess and id (say, 35) and create a url like:

    http://example.com/gallery3/print_photo/35

This will give me a url that lets me view the full size.  No permission
checks have been run.  This is a security hole.  print_photo needs to
verify that the caller can view the full size before it creates a proxy
for it.

Are you confusing print_photo() and print_proxy() here?  print_proxy()
requires the $uuid (might help if you renamed the variables in the
method definition to make that more clear).


>    3. "I'd simplify all of this and ditch the advanced mode altogether.
>       It's way too much choice and text for G3.  Plus all the marketing
>       stuff on the settings page.. that all looks like G2."
 >
>       I've cut out most of the cruft so its a lot lighter and not so g2
>       like.  I'd prefer being able to enter my own company and event id,
>       so I'd rather not have to go to advanced settings.  In fact, if we
>       weren't time constrained I would have implemented the patch I had
>       created for g2 to allow event ids to be assigned to groups and users.

You're an edge case.  Don't optimize for yourself here.  Right now if I
go to that page I'm mightily confused.  I'm presented with a signup page
and a couple of empty text boxes.  I don't care about any of that
stuff-- I just want to allow people to make prints.  Start with the
simplest possible thing-- hardcode the values and don't make them
editable.  The point in making Admin > Settings > Advanced is so that we
*don't* have to create a confusing UI just to support our power users.
More work needed here.

>    4. "ditch basic_company_id and basic_event_id and just have the
>       company_id and event_id prefilled.  Don't even allow users to
>       change them for now (advanced users can always change those values
>       in Admin > Settings > Advanced later on.  Perhaps add some simple
>       text and a link to the Digibug site and their logo"
 >
>       I like having the basic settings, so an admin can switch back and
>       forth.  I guess what I could do (and maybe this what your saying)
>       is bag the tabs, just have the content that's on the advanced and
>       add a "default" button to reset to gallery's company and event ids

More of what I said above.  This is still too confusing.  Let's start by
supporting our 80% case.  Those users want to activate the module, do
zero configuration, and have print buttons appear.  Realistically, we
could just ditch the Digibug settings page altogether for 3.0 and put up
a FAQ telling people how to sign up and change their ids and.

>    6. Just thought of this... how do you want to handle non jpeg
>       images.  The Digibug api will only handle jpegs.  Not show the
>       button if its not a jpeg? (simple and quick) or do a conversion
>       (more complete, but a pita to manage the converted image).  I'm
>       leaning to the first option.

I like #1.

>    7. Will try to put the digibug window into an iframe in a dialog and
>       see how that works (Chad's suggestion)

I just tried printing and got this error:

There was an SQL error: Table 'g3dev.g3_digibug_proxies' doesn't exist -
SHOW COLUMNS FROM `g3_digibug_proxies`

I haven't looked at the code, but I'm guessing this means that you
modified the database but didn't add upgrade support?  I guess we don't
have a policy for what we do in that case, but now that we're post-beta
we should do our best to support upgrades for any changes that we make.

I think this means that we don't commit stuff back to the main repo
until it's passed some level of review, and once its in the main repo we
support the proper upgrade path.

I doubt many people have been bitten by this so far, so I think the
easiest thing to do is to seek forgiveness in this case, but in the
future we should probably keep modules out of the main repo until you
and I agree on the structure first to avoid writinga lot of upgrade code.

-Bharat

PS: for anybody playing along at home, you might want to drop the
"proxies" table from your g3dev if you installed the digibug module
yesterday.


------------------------------------------------------------------------------
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]