[FIX (Maybe ; ))]: Issue 14959: MC Hook for Default Credentials
Fix in inbox: SLICE-Issue-14959-MC-Hook-for-Default-Credentials-SeanDeNigris.1 When creating a repo in the MC Browser, it would be great to pre-populate the user and password fields. Thus, we declare a CredentialSource role collaborating with MCHttpRepository and subclasses. The in-kernel default is a no-op Null object, but users can install (via MCHttpRepository class>>#credentialSource:) any object that responds to #defaultUserFor: and #defaultPasswordFor: I'd like to apply this to Gofer, too, but I found a big switch statement in ZnUrl>>#mcRepositoryAsUser:withPassword: and now my head hurts ;) Anyway maybe this will spur discussion... ----- Cheers, Sean -- View this message in context: http://forum.world.st/FIX-Maybe-Issue-14959-MC-Hook-for-Default-Credentials-... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 19 Feb 2015, at 03:15, Sean P. DeNigris <sean@clipperadams.com> wrote:
Fix in inbox: SLICE-Issue-14959-MC-Hook-for-Default-Credentials-SeanDeNigris.1
When creating a repo in the MC Browser, it would be great to pre-populate the user and password fields.
Thus, we declare a CredentialSource role collaborating with MCHttpRepository and subclasses. The in-kernel default is a no-op Null object, but users can install (via MCHttpRepository class>>#credentialSource:) any object that responds to #defaultUserFor: and #defaultPasswordFor:
I'd like to apply this to Gofer, too, but I found a big switch statement in ZnUrl>>#mcRepositoryAsUser:withPassword: and now my head hurts ;)
Yes, that is not good (ahem). We should let the root, MCRepository, decide, probably doing a lookup through its subclasses. All subclasses should also uniformly take credentials.
Anyway maybe this will spur discussion...
----- Cheers, Sean -- View this message in context: http://forum.world.st/FIX-Maybe-Issue-14959-MC-Hook-for-Default-Credentials-... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
2015-02-19 11:11 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:
On 19 Feb 2015, at 03:15, Sean P. DeNigris <sean@clipperadams.com> wrote:
Fix in inbox: SLICE-Issue-14959-MC-Hook-for-Default-Credentials-SeanDeNigris.1
When creating a repo in the MC Browser, it would be great to pre-populate the user and password fields.
Thus, we declare a CredentialSource role collaborating with MCHttpRepository and subclasses. The in-kernel default is a no-op Null object, but users can install (via MCHttpRepository class>>#credentialSource:) any object that responds to #defaultUserFor: and #defaultPasswordFor:
I'd like to apply this to Gofer, too, but I found a big switch statement in ZnUrl>>#mcRepositoryAsUser:withPassword: and now my head hurts ;)
Yes, that is not good (ahem).
We should let the root, MCRepository, decide, probably doing a lookup through its subclasses. All subclasses should also uniformly take credentials.
Yes! I want an end to that big switch ! (I had to write an override to that to get gitfiletree:// urls to work, as well as two or three other spots in Zn where known url protocols are hardcoded). Thierry
Anyway maybe this will spur discussion...
----- Cheers, Sean -- View this message in context: http://forum.world.st/FIX-Maybe-Issue-14959-MC-Hook-for-Default-Credentials-... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 19 Feb 2015, at 11:20, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2015-02-19 11:11 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:
On 19 Feb 2015, at 03:15, Sean P. DeNigris <sean@clipperadams.com> wrote:
Fix in inbox: SLICE-Issue-14959-MC-Hook-for-Default-Credentials-SeanDeNigris.1
When creating a repo in the MC Browser, it would be great to pre-populate the user and password fields.
Thus, we declare a CredentialSource role collaborating with MCHttpRepository and subclasses. The in-kernel default is a no-op Null object, but users can install (via MCHttpRepository class>>#credentialSource:) any object that responds to #defaultUserFor: and #defaultPasswordFor:
I'd like to apply this to Gofer, too, but I found a big switch statement in ZnUrl>>#mcRepositoryAsUser:withPassword: and now my head hurts ;)
Yes, that is not good (ahem).
We should let the root, MCRepository, decide, probably doing a lookup through its subclasses. All subclasses should also uniformly take credentials.
Yes! I want an end to that big switch !
(I had to write an override to that to get gitfiletree:// urls to work, as well as two or three other spots in Zn where known url protocols are hardcoded).
Yes, you told me that at the Pharo Days, maybe you could show me what you had to override and what was bothering you ?
Thierry
Anyway maybe this will spur discussion...
----- Cheers, Sean -- View this message in context: http://forum.world.st/FIX-Maybe-Issue-14959-MC-Hook-for-Default-Credentials-... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
2015-02-19 11:28 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:
On 19 Feb 2015, at 11:20, Thierry Goubier <thierry.goubier@gmail.com> wrote:
....
Yes! I want an end to that big switch !
(I had to write an override to that to get gitfiletree:// urls to work, as well as two or three other spots in Zn where known url protocols are hardcoded).
Yes, you told me that at the Pharo Days, maybe you could show me what you had to override and what was bothering you ?
Hum: The overrides I have are: ZnUrl class>>defaultPortForScheme: (I think it appears on error paths through Zn) ZnUrl>>McRepositoryAsUser:withPassword: (Where things missing would also be the github:// and the bibucket:// urls... I believe you can't use them via Gofer because of that). and ZnUrl>>asFileReference (Where there is an assert). I believe ZnUrl>>enforceKnownScheme is also problematic. I just searched through all ZnURL methods containing #http :) Thierry
I was thinking that we could use Author to provide a password because this is boring to always have to type it. Stef Le 19/2/15 03:15, Sean P. DeNigris a écrit :
Fix in inbox: SLICE-Issue-14959-MC-Hook-for-Default-Credentials-SeanDeNigris.1
When creating a repo in the MC Browser, it would be great to pre-populate the user and password fields.
Thus, we declare a CredentialSource role collaborating with MCHttpRepository and subclasses. The in-kernel default is a no-op Null object, but users can install (via MCHttpRepository class>>#credentialSource:) any object that responds to #defaultUserFor: and #defaultPasswordFor:
I'd like to apply this to Gofer, too, but I found a big switch statement in ZnUrl>>#mcRepositoryAsUser:withPassword: and now my head hurts ;)
Anyway maybe this will spur discussion...
----- Cheers, Sean -- View this message in context: http://forum.world.st/FIX-Maybe-Issue-14959-MC-Hook-for-Default-Credentials-... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
stepharo wrote
I was thinking that we could use Author
Ah, yes. That might be a good place. We have KeyChain in the image. I wonder what the status of that is. It seems like it was designed for this purpose... ----- Cheers, Sean -- View this message in context: http://forum.world.st/FIX-Maybe-Issue-14959-MC-Hook-for-Default-Credentials-... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (4)
-
Sean P. DeNigris -
stepharo -
Sven Van Caekenberghe -
Thierry Goubier