New authorization library moved to kdereview

Albert Astals Cid aacid at kde.org
Wed Jul 22 21:48:22 BST 2009


A Divendres, 17 de juliol de 2009, Nicola Gigante va escriure:
> Hello everybody,
>
> I'm the summer of code student who is writing the new authorization
> library for kde.
> I'm very pleased to announce that, as suggested by my mentor Dario
> Freddi, the library is mature enough for review. It is feature-
> complete, fully documented, and only needs some testing.
>
> The new library allows developers to easily adopt the caller/helper
> pattern to write applications that perform privileged task without the
> need to run the whole GUI as root, in a secure and cross-platform way.
> The library uses PolicyKit as the backend on linux/unix systems, and
> Authorization Services on OSX. A windows backend is still to be
> written (I could look about it in the future, however it's not a
> required part of my gsoc project).
> Both the policykit and mac backends are feature-complete.
>
> I moved the code to kdereview/libkauth for inclusion in KDE. My mentor
> and I aren't sure about where it should be placed. I think putting it
> in kdelibs will make its adoption easier by kde developers, but
> kdesupport is also a choice.
>
> If you want to see how the API looks like, I've written a complete
> apidox. The provided example (a text editor that can read/write files
> with root permissions) shows most of the features.
> It currently is a Qt-only library.
>
> The next step in my project will be adding some features to GUI
> components like KAction and KPushButton to let developers use
> immediately use the library.
>
> Please tell me any comment/suggestion/critic about my work.

Hi, some comments from my side:

 * maybe rename the namespace to KAuth?

 * The code is GPL, we don't accept GPL code in kdelibs.

 * You have functions that return references (e.g. ActionReply.h), if somewhen 
your internal storage changes you won't be able of returning references ending 
up in a BC problem, you should avoid/remove them

 * static ActionReply deserialize(QByteArray data); should probably get a 
const &

 * void ActionWatcher::actionPerformedSlot(const QString &action, ActionReply 
reply); should get a const &?

 * void ActionWatcher::progressStepSlot(const QString &action, QVariantMap 
data); should get a const &?

 * static void HelperSupport::progressStep(QVariantMap data); should get a 
const &?

 * Having inline code in headers is bad (~AuthBackend())

 * this->statusBar()-> is "ugly", kill the this->

 * AuthStatus executeAsync(QObject *target = NULL, const char *slot = NULL); 
in KDE we usually use 0 and not NULL

 * const QString &helperID = "" would be better const QString &helperID = 
QString()

 * I'm not sure if doing forward declaration of QMap (HelperProxy.h) is a good 
idea

 * You have some  static const ActionReply SuccessReply; i'm not sure if 
that's ok or you have to use some K_STATIC_FOO macro, can someone clarify it?

Albert

>
> Thank you,
>
> Nicola





More information about the kde-core-devel mailing list