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