Hi Steffen. Thanks for sharing the set of edusharing plugins with the community. Please note, all the "Recommended" warnings reported above should really be considered as required as we insist on them before approving the plugin (they will be marked as required in the next version of the plugins directory UI). Please pay attention to them and fill them. Thanks for understanding.

Hi Steffen. Apologies for the delays with the review and approval process. Your plugins are #1 in the list of plugins waiting for re-approval and I am sure we will get to them this week.

Hi Steffen. We finally got to looking at the submitted code. Firstly, the edu-sharing looks like an interesting project to support teachers. Well done on that. We are happy to see Moodle supported.

While reviewing the code of your plugins, I noticed couple of issues that I should be addressed before the plugin is approved here. Some notes I took while reading the code:

• Generally the coding style is quite far away from the standards we would like to set up and maintain here. Please review the https://docs.moodle.org/dev/Plugin_contribution_checklist and https://docs.moodle.org/dev/Coding_style again and try to fix all the violations.
• Just a quick overview shows that the rules for naming the constants and functions are not always followed. On contrary, the class mod_edusharing_sig_soap_client has all methods prefixed with the frankenstyle name for no good reason.
• Incoming request superglobals are accessed directly without parameter cleaning.
• SOAP extension is optional in Moodle. However, your plugin relies on it and it should be better documented in the plugin description, readme and via the environment.xml file.
• The upgrade code uses some custom locally available files in db/upgrade.php. It does not seem to be valid for majority of installations that will install the plugin from this plugins directory.
• Also please note that using the DIRECTORY_SEPARATOR constant in a away you do in that file makes it only hard to read. Just use the forward slashes like Moodle core does, it works on all platforms.
• Some strings are not provided via language packs but are hard-coded in the code (some in English, some in German).
• Files like signatureRedirector.php in the filter represent a potential security risk - they could be abused to redirect another user to a malicious page easily. Places like this should have strict input validation and heavy sesskey protection.

I know you have been waiting in the approval queue for a long time now. But I am sure it will help the integration if the implementation follows the Moodle coding style more. I am going to mark this as needing more work. Once there are new versions uploaded here, please schedule the plugins for re-approval again.

Thanks for your patience with the review and approval process.

Basically, yes. See https://docs.moodle.org/dev/Security:Cross-site_request_forgery for details.

Thanks Steffen for providing the updated versions promptly. I've been playing with a demo available at your project site.

There are certain areas in the code which I think could be reconsidered from both Moodle and edu-sharing API perspective - such as sending the raw value of session_id() as a session ticket to the remote server. Also the way how your Moodle plugins deal with session storage (e.g. directly setting properties like $_SESSION["USER"]->ticket) are warmly discouraged in common Moodle plugins. I can understand it may not be always possible to follow these guidelines as the other side of the integration (edu-sharing server and its API) may be limiting factor as well.

I am going to approve these plugins now. Good luck in further maintenance a development of the project. You are cleared to land, welcome to the Plugins directory.

Please note string definitions like $string['modulename'] = $string['pluginname'] = '...'; are not supported by the AMOS parser at lang.moodle.org (we do not eval() these files) so we could not register strings of your plugin there.