Development/Tutorials/KAuth/Helper HowTo - Revision history

AnneW at 15:34, 19 July 2012

2012-07-19T15:34:25Z

Neverendingo: Text replace - "" to ""

2011-06-30T10:19:42Z

Text replace - "<syntaxhighlight lang="make">" to "<syntaxhighlight lang="cmake">"

Neverendingo: Text replace - "`" to ""`


2011-06-29T19:44:29Z
Text replace - "<code cmake>" to "<syntaxhighlight lang="make">"

				
				
				
				
			
			← Older revision
			Revision as of 19:44, 29 June 2011
			
Line 157:
Line 157:
  At this point, let's see how to compile the helper:   At this point, let's see how to compile the helper:
    
− <code cmake> + <syntaxhighlight lang="make">
  kde4_add_executable(kauth_example_helper  helper.cpp)   kde4_add_executable(kauth_example_helper  helper.cpp)
  target_link_libraries(kauth_example_helper ${KDE4_KDECORE_LIBS})   target_link_libraries(kauth_example_helper ${KDE4_KDECORE_LIBS})

`Neverendingo: Text replace - "`" to ""

2011-06-29T19:42:16Z

Text replace - "</code>" to "</syntaxhighlight>"

Neverendingo: Text replace - "`" to ""`


2011-06-29T19:38:47Z
Text replace - "<code cpp>" to "<syntaxhighlight lang="cpp">"

				
				
				
				
			
			← Older revision
			Revision as of 19:38, 29 June 2011
			
Line 57:
Line 57:
  Here's how a possible header can look like:   Here's how a possible header can look like:
    
− <code cpp> + <syntaxhighlight lang="cpp">
  #include <kauth.h>   #include <kauth.h>
    
Line 82:
Line 82:
  Let's try implementing the ''read'' action:   Let's try implementing the ''read'' action:
    
− <code cpp> + <syntaxhighlight lang="cpp">
  ActionReply MyHelper::read(QVariantMap args)   ActionReply MyHelper::read(QVariantMap args)
  {   {
Line 114:
Line 114:
  If the action you have to perform is long, you probably want to report the application some kind of progress or real time data. Let's see how to do it by implementing ''longaction''.   If the action you have to perform is long, you probably want to report the application some kind of progress or real time data. Let's see how to do it by implementing ''longaction''.
    
− <code cpp> + <syntaxhighlight lang="cpp">
  ActionReply MyHelper::longaction(QVariantMap args)   ActionReply MyHelper::longaction(QVariantMap args)
  {   {
Line 140:
Line 140:
  The helper supports remote debugging through qDebug. This means that every call to qDebug() and friends will be reported to the application, and printed using the same qt debugging system, with the same debug level. So such a call in any actions of your helper:   The helper supports remote debugging through qDebug. This means that every call to qDebug() and friends will be reported to the application, and printed using the same qt debugging system, with the same debug level. So such a call in any actions of your helper:
    
− <code cpp> qDebug() << "I'm in the helper";</code> + <syntaxhighlight lang="cpp"> qDebug() << "I'm in the helper";</code>
    
  will print the following in the main application:   will print the following in the main application:
Line 151:
Line 151:
  When you are done with your helper implementation, you have to add some small things to it and to your buildsystem to make it work. First of all, at the bottom of your helper's cpp file, you'll have to put the following macro:   When you are done with your helper implementation, you have to add some small things to it and to your buildsystem to make it work. First of all, at the bottom of your helper's cpp file, you'll have to put the following macro:
    
− <code cpp>KDE4_AUTH_HELPER_MAIN("org.kde.auth.example", MyHelper)</code> + <syntaxhighlight lang="cpp">KDE4_AUTH_HELPER_MAIN("org.kde.auth.example", MyHelper)</code>
    
  Which accepts as a parameter the helper identifier, and the class name of the helper itself. This macro will take care of generating the needed main function for the helper and all the required code for interaction with the authorization system.   Which accepts as a parameter the helper identifier, and the class name of the helper itself. This macro will take care of generating the needed main function for the helper and all the required code for interaction with the authorization system.



Artemis Fowl at 00:18, 26 February 2011
2011-02-26T00:18:15Z


				
				
				
				
			
			← Older revision
			Revision as of 00:18, 26 February 2011
			
Line 97:
Line 97:
    
       QTextStream stream(&file);        QTextStream stream(&file);
−      QString contents; +      QString contents = stream.readAll();
−     stream >> contents; + 
    
       QVariantMap retdata;        QVariantMap retdata;





Artemis Fowl at 17:32, 25 February 2011
2011-02-25T17:32:26Z


				
				
				
				
			
			← Older revision
			Revision as of 17:32, 25 February 2011
			
Line 103:
Line 103:
       retdata["contents"] = contents;        retdata["contents"] = contents;
    
−      reply.setData(contents); +      reply.setData(retdata);
       return reply;        return reply;
  }   }



Drf at 13:17, 12 February 2010
2010-02-12T13:17:35Z


				
				
				
				
			
			← Older revision
			Revision as of 13:17, 12 February 2010
			
Line 175:
Line 175:
    
  ''user'' is the user under which the helper will be run, in this case root. But if, for example, you're creating an helper to modify a file owned and editable by the user "apache", you can make the helper be run by "apache" and be even more secure.   ''user'' is the user under which the helper will be run, in this case root. But if, for example, you're creating an helper to modify a file owned and editable by the user "apache", you can make the helper be run by "apache" and be even more secure.
  + 
  + == Conclusion ==
  + In the end, the main steps for creating an helper are:
  + 
  + *Creating a corresponding .actions file
  + *Implementing the helper class
  + *Adding KDE4_AUTH_HELPER_MAIN macro to the helper's cpp file
  + *Build the helper as described above
  + 
  + As you have seen the process is quite straightforward and well matched, both API and behavior wise, to what happens in the caller. Remember to keep in mind all the needed conventions and caveats, mainly for the action namespaces and the header's signatures.



Drf at 12:17, 12 February 2010
2010-02-12T12:17:52Z


				
				
				
				
			
			← Older revision
			Revision as of 12:17, 12 February 2010
			
Line 11:
Line 11:
  next=[[Development/Tutorials/KAuth/KCM_HowTo|Creating a KCM requiring authorization upon saving]]|     next=[[Development/Tutorials/KAuth/KCM_HowTo|Creating a KCM requiring authorization upon saving]]|  
    
− reading=[http://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/classKAuth_1_1Action.html KAuth::Action Class Reference] + reading=[http://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/namespaceKAuth_1_1HelperSupport.html KAuth::HelperSupport Namespace Reference]
  }}   }}
    





Drf at 14:58, 11 February 2010
2010-02-11T14:58:53Z


				
				
				
				
			
			← Older revision
			Revision as of 14:58, 11 February 2010
			
Line 149:
Line 149:
  Remember that the debug level is preserved, so if you use qFatal() you won't only abort the helper (which isn't suggested anyway), but also the application.   Remember that the debug level is preserved, so if you use qFatal() you won't only abort the helper (which isn't suggested anyway), but also the application.
    
− ===Completing the helper=== + ===Needed macros and CMake===
− When you implemented + When you are done with your helper implementation, you have to add some small things to it and to your buildsystem to make it work. First of all, at the bottom of your helper's cpp file, you'll have to put the following macro:
  +  
  + <code cpp>KDE4_AUTH_HELPER_MAIN("org.kde.auth.example", MyHelper)</code>
  +  
  + Which accepts as a parameter the helper identifier, and the class name of the helper itself. This macro will take care of generating the needed main function for the helper and all the required code for interaction with the authorization system.
  +  
  + At this point, let's see how to compile the helper:
  +  
  + <code cmake>
  + kde4_add_executable(kauth_example_helper  helper.cpp)
  + target_link_libraries(kauth_example_helper ${KDE4_KDECORE_LIBS})
  + install(TARGETS kauth_example_helper DESTINATION ${LIBEXEC_INSTALL_DIR})
  +  
  + kde4_install_auth_helper_files(kauth_example_helper org.kde.auth.example root)
  + </code>
  +  
  + Let's see each macro one at a time: of course the first two create the helper executable and link it to the needed libraries (only kdecore is needed for a basic helper).
  +  
  + The install macro '''has to install the helper in ${LIBEXEC_INSTALL_DIR}'''. Installing it elsewhere will prevent the helper from working.
  +  
  + ''kde4_install_auth_helper_files'' generates and installs all the needed files for the helper to work: this macro has the following format:
  +  
  +  kde4_install_auth_helper_files(<helper_cmake_target> <helper_id> <user>)
  +  
  + ''user'' is the user under which the helper will be run, in this case root. But if, for example, you're creating an helper to modify a file owned and editable by the user "apache", you can make the helper be run by "apache" and be even more secure.

← Older revision		Revision as of 15:34, 19 July 2012
Line 1:		Line 1:
−	~~{{Template:I18n/Language Navigation Bar\|Development/Tutorials/KAuth/KAuth Actions}}~~	+

	{{TutorialBrowser\|		{{TutorialBrowser\|

@@ Line 71: / Line 71: @@
          ActionReply longaction(QVariantMap args);
 };
-</code>
+</syntaxhighlight>
 The first thing you should note is ''using namespace KAuth''. This directive is compulsory as each action's signature must look like this:
@@ Line 105: / Line 105: @@
      return reply;
+}
-</code>
+</syntaxhighlight>
 The QVariantMap received by read is nothing else but the arguments set through ''Action::setArguments()'' by the caller. This way you can call any action with any custom argument. The action above opens a file and streams back the contents to the caller.
@@ Line 131: / Line 131: @@
      return ActionReply::SuccessReply;
+}
-</code>
+</syntaxhighlight>
 There are two things to note here: the first is that the helper can accept stop requests, as you have seen in the [[Development/Tutorials/KAuth/KAuth_Actions|KAuth actions tutorial]], but it's up to you whether to accept them or not. You can check if you have a stop request pending through HelperSupport::isStopped and then act accordingly.
@@ Line 140: / Line 140: @@
 The helper supports remote debugging through qDebug. This means that every call to qDebug() and friends will be reported to the application, and printed using the same qt debugging system, with the same debug level. So such a call in any actions of your helper:
-<syntaxhighlight lang="cpp"> qDebug() << "I'm in the helper";</code>
+<syntaxhighlight lang="cpp"> qDebug() << "I'm in the helper";</syntaxhighlight>
 will print the following in the main application:
@@ Line 151: / Line 151: @@
 When you are done with your helper implementation, you have to add some small things to it and to your buildsystem to make it work. First of all, at the bottom of your helper's cpp file, you'll have to put the following macro:
-<syntaxhighlight lang="cpp">KDE4_AUTH_HELPER_MAIN("org.kde.auth.example", MyHelper)</code>
+<syntaxhighlight lang="cpp">KDE4_AUTH_HELPER_MAIN("org.kde.auth.example", MyHelper)</syntaxhighlight>
 Which accepts as a parameter the helper identifier, and the class name of the helper itself. This macro will take care of generating the needed main function for the helper and all the required code for interaction with the authorization system.
@@ Line 163: / Line 163: @@
 kde4_install_auth_helper_files(kauth_example_helper org.kde.auth.example root)
-</code>
+</syntaxhighlight>
 Let's see each macro one at a time: of course the first two create the helper executable and link it to the needed libraries (only kdecore is needed for a basic helper).

← Older revision		Revision as of 13:17, 12 February 2010
Line 175:		Line 175:

	''user'' is the user under which the helper will be run, in this case root. But if, for example, you're creating an helper to modify a file owned and editable by the user "apache", you can make the helper be run by "apache" and be even more secure.		''user'' is the user under which the helper will be run, in this case root. But if, for example, you're creating an helper to modify a file owned and editable by the user "apache", you can make the helper be run by "apache" and be even more secure.
		+
		+	== Conclusion ==
		+	In the end, the main steps for creating an helper are:
		+
		+	*Creating a corresponding .actions file
		+	*Implementing the helper class
		+	*Adding KDE4_AUTH_HELPER_MAIN macro to the helper's cpp file
		+	*Build the helper as described above
		+
		+	As you have seen the process is quite straightforward and well matched, both API and behavior wise, to what happens in the caller. Remember to keep in mind all the needed conventions and caveats, mainly for the action namespaces and the header's signatures.