On Wednesday 08 July 2009 22:27:24 Aaron J. Seigo wrote: > personally, what i'd expect is the ability to set the authorization > interface either using an AuthorizationInterface* or by just calling > AuthorizationManager::setAuthorizationInterface() with a enum as the > parameter, with the enums mapping to these internal classes. > > so a shell can either go "standard" or "custom". > > the standards might include DenyAllAuthorization, PinPairingAuthorization, > CertificateAuthorization? pin pairing should include certificate auth, i'd > think, as well... but yes, then there's no need to make any of it public.
Sounds like a good idea. Indeed PinPairingAuthorization will only actually do pin pairing if there isn't already some trusted gpg key or something like that we could use to validate it's identity. I assume btw that it's safe to, when adding support for GPG, sign the QCA::PublicKey we use for signing/validating, and check if that GPG key is in some trusted key ring? That way, there's just a single code path for signing validating (just RSA or DSA keys, which doesn't really mind since they both implement QCA::PublicKey), and GPG (which has a completely different API in QCA) is just some addition on top of that. And the shell can just check Identity::isTrusted() to see if it is trusted even if in the future different method for establishing trust are used. Hmm, now that I'm thinking about the Identity class: what if I, besides validating signatures, also put signing there (with identities that aren't the local machine just not being able to sign because of the lack of a privatekey), create some identity "me" in AuthorizationManager, and a second constructor that creates a private/public key pair. Then, if instead of QCA::PublicKey the constructor accepts the key as a QByteArray, ALL QCA related stuff (hmm, except tokens, well, let's say ALL crypto) will be encapsulated by Identity. Hell, we could then even switch out QCA entirely for something else in the probably unlikely case that QCA would become unmaintained. I'd like that.... > something else in AccessManager: > > ServiceAccessJob* accessService(KUrl location) const; > > the url is said to be, in the dox: > > * @param location a valid JOLIE url > > besides not wanting to really expose JOLIE too much in the api, this is not > going to work out well for other modes of transit. same will go for > retrieving applets. > > while it's just fine to have only JOLIE created right now, i think we > should keep the possibility open for other mechanisms. JOLIE may not be an > option on some devices, particularly very small ones. so while plasma:// > would be synonymous with "this is a JOLIE driven service" or "this is an > applet we're going to grab using JOLIE", i do plan on writing an emb:// (or > whatever) handler that does things in a rather more direct fashion between > plasma and a device. the only major difference is the kind of service it > returns (it would obviously speak a slightly different protocol) and how it > retrieves the applet/service/etc. > > now, this doesn't impact the external API at all, but the apidox should > probably be changed and the backend code should remain flexible enough to > have this added in future. Hmm, I didn't really think about bypassing jolie, but it's a good idea, and not hard to accomplish. Only in AuthorizationManager there are currently some Jolie::Message parameters for certain functions, but these functions usually only need a couple of fields from such a message, so I could replace them with some QByteArrays/QStrings. In which case the only place that does Jolie specific stuff would be RemoteService/RemoteServiceJob/ServiceProvider. Which would be neat: for a different future protocol (what IS emb:///?) All you need is a different implementation of those classes, and you'll have your different protocol. At the exact same way we could even version the JOLIE based protocol: See if the other side supports the newer version and then instantiate RemoteServiceV2 instead. We could even make those plugins, but let's not start with that :p > > I hate it if there are two > > methods for service access though (Service *serviceForSource and > > ServiceAccessJob *accessService). > > there are actually more than two; you can ask for a service from a local > plugin as well using Plasma::Service::load. there's nothing that says > services must be attached a DataEngine, after all. > > that said, they all have completely different use cases, and in the case of > serviceForSource, if it's a remote engine it should be using accessService > in the background. so for the users of services today in plasma, it will be > completely transparent and the API is just there as an implementation > detail to them, no? Yeah, true. > > Another option would be to have > > accessService in AccessManager and have it still return a Service *, but > > that would make it inconsistent with accessApplet. > > i think the accessService should just return a Service*, since Service is > (now, anyways :) fully async, and accessApplet should return a job because > applets are _not_ async. it's not inconsistent really, it's just that the > two kinds of objects behave very differently. Ok, so to summarize: Default implementations AuthorizationInterface become private and settable by Enum Only have Jolie specific stuff in RemoteService/RemoteServiceJob/ServiceProvider Have all QCA crypto stuff in identity. Alright? Let's put on my refactoring hat. ... pitty refactoring support for kdevelop is still a WiP :p Oh, on a related topic: Suppose we're going to connect to a remote nowplaying applet. That applet uses the nowplaying dataengine and possibly nowplaying service. So when we succesfully connect with the service that provides the applet, that service should also: * make sure nowplaying dataengine is published (service will be published as a response to serviceForSource) * create an AuthorizationRule for that identity that allows it access to nowplaying dataengine and applet. So we need tok now which other services an applet uses so we can put all the light on green. (people probably wouldn't like having to Pin pair for all engines used by an applet as well :p). How it currently works however is that the applet's config contains a section with names of dataengines and the urls they point to. Which is not enough to acccomplish this. So there are two ways to do this: * Include a list of 'dependencies' in the applet's .desktop * Invoke a dataEngine operation on the service providing the applet that will publish the dataengine (if not already published) and add a rule allowing the caller to access that engine. the last option looks quite good, but it does give a little less flexibility. Theoratically, you could now configure a local applet to use dataengine a from machine A and dataengine b from machine B, which will be lost with that approach. I don't know how important it is to be able to do that kind of insane stuff ;) Regards, Rob _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
