Support password-protected appcasts

This is important for beta branches.

How do we store the username/password? Have SUAppcastUsername / SUAppcastPassword keys which are taken from NSUserDefaults / Info.plist? Do we want to popup a dialog asking for the username/password in case none are given (and store them in NSUserDefaults) - this would add another .nib file though.

Also, this would require a restructuring of the appcast fetching, since right now Sparkle uses [RSS initWithURL:userAgent:delegate:]. Factoring the NSURLConnection code out of RSS.m and into SUAppcast.m would be generally desirable, IMHO. Implementing authentication would then be very easy by adding the connection:didReceiveAuthenticationChallenge: delegate.

I've already been extensively modifying the RSS class for Sparkle's needs, so it shouldn't be that bad: implement the delegate method in RSS by passing it along the RSS's delegate (namely the SUAppcast instance). The SUAppcast is model—it's not allowed to be doing stuff like displaying a pop-up—so have it ask *its* delegate (the driver) for a username and password, which it can then store in the keychain. Then we can do things like making the scheduled driver not ask for a password while the user-initiated one should.

I've been thinking of the following approach: If we have credentials (from the Info.plist or Keychain) pass them to whoever handles the NSURLConnection so the connection:didReceiveAuthenticationChallenge: delegate call can supply these credentials. If they turn out to be wrong, or we don't have credentials, I'd let the connection fail and pass the error back to whoever initiated it. The initiator can then decide if asking for credentials is appropriate, run the dialog and restart the appcast fetch (with credentials this time). This prevents that a) the NSURLConnection handler has to determine whether asking is okay and b) it has to run the dialog and wait asynchronously for the result - both things which other parts of the framework should handle.

I see that RSS.m is not what it once was anyway, so I guess adding the connection:didReceiveAuthenticationChallenge: delegate there would be okay. I think we'd setUsername: setPassword: on the SUAppcast instance which in turn would set it on the RSS instance.

That sounds good, except setUsername:setPassword: seems kind of weird since it only actually applies to the fetch method; otherwise, the appcast is just model. Probably put them as parameters if we have them?

Any progress on this, Jonas?

I'm interested in such functionality as well. I use private beta testing for an application I'm developing. I'd like to make the app case public so that the app can detect and notify the user automatically if an update is available, then, if the user wants to proceed with an update they would be prompted for the correct username and password. This is probably a step beyond what has already been mentioned here. Any chance such functionality will ever be implemented?

I'd welcome a patch in the future, but for the moment, Sparkle's feature frozen.

Right, I noticed that, but how long will the feature freeze last? Just
until 1.5 is officially released right?

On Thu, Sep 18, 2008 at 2:26 PM, Andy Matuschak <email address hidden> wrote:
> I'd welcome a patch in the future, but for the moment, Sparkle's feature
> frozen.
>
> --
> Support password-protected appcasts
> https://bugs.launchpad.net/bugs/228458
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Sparkle Updater: In Progress
>
> Bug description:
> Sparkle should support appcasts and update archives which are behind simple HTTP authentication.
>

Yeah.

On Sep 18, 2008, at 11:53 AM, Will Stokes wrote:

> Right, I noticed that, but how long will the feature freeze last? Just
> until 1.5 is officially released right?
>
> On Thu, Sep 18, 2008 at 2:26 PM, Andy Matuschak <<email address hidden>
> > wrote:
>> I'd welcome a patch in the future, but for the moment, Sparkle's
>> feature
>> frozen.
>>
>> --
>> Support password-protected appcasts
>> https://bugs.launchpad.net/bugs/228458
>> You received this bug notification because you are a direct
>> subscriber
>> of the bug.
>>
>> Status in Sparkle Updater: In Progress
>>
>> Bug description:
>> Sparkle should support appcasts and update archives which are
>> behind simple HTTP authentication.
>>
>
> --
> Support password-protected appcasts
> https://bugs.launchpad.net/bugs/228458
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Sparkle Updater: In Progress
>
> Bug description:
> Sparkle should support appcasts and update archives which are behind
> simple HTTP authentication.

Anyone?

Hey guys,

I'm brand new to sparkle and launchpad, sorry if this is misplaced or no longer relevant.

I needed http auth, so I added it earlier this week in my local copy of 1.5 b6, via a simple drop-down sheet if there's a foreground update or an alert if it's an automatic background update.

Is this of use to anyone? If so, easy way for me to contribute it back? Since I'm not a sparkle contributor and have no familiarity with the development history, I'd rather not be committing it to a repository, but I can email to someone that can.

Cheers. Thanks Andy, and everyone else who's helped, for Sparkle. It's a real gift to the mac community.

Dan

That would be fantastic, Dan! If you've checked Sparkle out using bzr, it'd be really amazing if you could make a branch with your fix so others can easily incorporate it and stay current. Docs for doing that are here: http://andymatuschak.org/articles/2008/06/01/a-guide-to-contributing-to-sparkle/

Alternately, attaching the patch to this bug would work.

Thanks a lot!