Non-core contributed modules

Adobe Connect SSO

Details

  • Type: New Feature New Feature
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 1.9
  • Fix Version/s: None
  • Component/s: Block: Adobeconnect
  • Labels:
    None
  • Affected Branches:
    MOODLE_19_STABLE

Description

Provides SSO with an Adobe Connect server

One-way synchronization, from Moodle to Adobe Connect; creates the course room the first time a course user accesses, as well as the user-room assignment and the user itself.

There are two capabilities, one for Adobe Connect "host" role, usually a teacher, and another for Adobe Connect "view" role.

The Adobe Connect room name becomes the Moodle course id (unique) and the users are created with the Moodle email as Adobe Connect username

Issue Links

This issue has been marked as being related by:
CONTRIB-1889 Adobe Connect Pro activity module Minor Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Anthony Borrow added a comment -

David - Many thanks for sharing the Adobe Connect block. I have a some comments, observations, and concerns about the block which I hope will be helpful.

1) Generally speaking, for security reasons it is preferred not to store the passwords, especially as simple text values to the Moodle database. If you are going to store them, I think it would be good store them in config_plugins (since the block is a plugin) rather than in config.

2) There seems to only be the option for one user to use the block. It would make since to me that you could have a block setting for each course or perhaps better for each user. The you may want to consider using the user_preferences table to store some of the data.

3) When loading the page with false host information, etc. I received a variety of PHP notices. Ideally I would work to avoid displaying these. I did not look at the code that produced them but if it is unable to connect then it should simply stop and display the error. I am attaching a screen capture of the various PHP notices I received.

4) The error message I received was [[Can\t get admin session]] which did not appear to be in the language file.

5) It appears that you can only add the block to courses and not the front page. This appeared counter-intuitive to me since there was only the option to store one username and password.

At this point, I am on the fence as to whether it would really be helpful/recommended to add it to CONTRIB (mostly because of the concern with the password). But the other issues make me question the overall helpfulness of the block. I would be willing to add it to Moodle's CVS server for you to continue working on it but I would recommend waiting to share it publicly with folks unless you wanted to invite others to help you with testing and providing feedback. If you choose to store the password in the database, I would recommend encrypting and decrypting it with something like mcrypt. At this point, if you could let me know what would be the best way to move forward. If you prefer to work on improving the code on Moodle's CVS that is fine or you may prefer just to hack away at it on your own a little bit. Either way, let me know how I can best be supportive. If you have any questions just let me know.

Peace - Anthony

Show
Anthony Borrow added a comment - David - Many thanks for sharing the Adobe Connect block. I have a some comments, observations, and concerns about the block which I hope will be helpful. 1) Generally speaking, for security reasons it is preferred not to store the passwords, especially as simple text values to the Moodle database. If you are going to store them, I think it would be good store them in config_plugins (since the block is a plugin) rather than in config. 2) There seems to only be the option for one user to use the block. It would make since to me that you could have a block setting for each course or perhaps better for each user. The you may want to consider using the user_preferences table to store some of the data. 3) When loading the page with false host information, etc. I received a variety of PHP notices. Ideally I would work to avoid displaying these. I did not look at the code that produced them but if it is unable to connect then it should simply stop and display the error. I am attaching a screen capture of the various PHP notices I received. 4) The error message I received was [[Can\t get admin session]] which did not appear to be in the language file. 5) It appears that you can only add the block to courses and not the front page. This appeared counter-intuitive to me since there was only the option to store one username and password. At this point, I am on the fence as to whether it would really be helpful/recommended to add it to CONTRIB (mostly because of the concern with the password). But the other issues make me question the overall helpfulness of the block. I would be willing to add it to Moodle's CVS server for you to continue working on it but I would recommend waiting to share it publicly with folks unless you wanted to invite others to help you with testing and providing feedback. If you choose to store the password in the database, I would recommend encrypting and decrypting it with something like mcrypt. At this point, if you could let me know what would be the best way to move forward. If you prefer to work on improving the code on Moodle's CVS that is fine or you may prefer just to hack away at it on your own a little bit. Either way, let me know how I can best be supportive. If you have any questions just let me know. Peace - Anthony
Hide
Permalink
Anthony Borrow added a comment -

here is the list of php notices captured

Show
Anthony Borrow added a comment - here is the list of php notices captured
Hide
Permalink
David Monllaó added a comment -

Hi,

Sorry Anthony, the usage info I provided it's totally insufficient; the block uses the adobe connect web services to create rooms, create users, assigns users to rooms and login users into adobe connect from moodle, in order to do that, we need to auth into adobe connect server as an AC administrator, after all the AC room and user checks, the $USER logins into adobe connect. That AC administrator is the user info required in the block config.

I prefer to work on the block before adding it to CVS to solve the issues you mention and upload a basic, but stable, block version:

  • block values in config_plugins (like ldap pwd for example)
  • I only hardcode error messages, but I'll put them all in the strings file
  • manage exceptions (what an horrible pic!)
  • Improve the README with usage instructions

Thanks a lot for you valuable time,
David

Show
David Monllaó added a comment - Hi, Sorry Anthony, the usage info I provided it's totally insufficient; the block uses the adobe connect web services to create rooms, create users, assigns users to rooms and login users into adobe connect from moodle, in order to do that, we need to auth into adobe connect server as an AC administrator, after all the AC room and user checks, the $USER logins into adobe connect. That AC administrator is the user info required in the block config. I prefer to work on the block before adding it to CVS to solve the issues you mention and upload a basic, but stable, block version:
  • block values in config_plugins (like ldap pwd for example)
  • I only hardcode error messages, but I'll put them all in the strings file
  • manage exceptions (what an horrible pic!)
  • Improve the README with usage instructions
Thanks a lot for you valuable time, David
Hide
Permalink
Anthony Borrow added a comment -

David - No worries, as you might imagine I bounce in and out of various blocks and pieces of code so even if you had made it obvious how the Adobe Connect stuff was to work I may have overlooked it. So it does make sense that you would have one set of credentials for a given server. For the password stuff, I would be surprised if there was not an API. I noticed that there is somewhat similar code for Drupal that you may be interested in at:

http://drupal.org/project/acrobat_connect

Also, some information for improving the password security stuff and logging in more securely may be found at:

http://www.adobe.com/support/connect/documentation.html and in particular in: http://help.adobe.com/en_US/Connect/6.0/WebServices/help.pdf (If you have not already seen these resources).

Thanks for your continued work on shoring it up and do not hesitate to let me know if I can be helpful in anyway. My goal is always to be supportive, helpful and encouraging. All of my comments should be considered suggestions so please use the ones that are helpful and avoid the ones that are not. Ultimately, it is your contribution and I trust you judgment.

Peace - Anthony

Show
Anthony Borrow added a comment - David - No worries, as you might imagine I bounce in and out of various blocks and pieces of code so even if you had made it obvious how the Adobe Connect stuff was to work I may have overlooked it. So it does make sense that you would have one set of credentials for a given server. For the password stuff, I would be surprised if there was not an API. I noticed that there is somewhat similar code for Drupal that you may be interested in at: http://drupal.org/project/acrobat_connect Also, some information for improving the password security stuff and logging in more securely may be found at: http://www.adobe.com/support/connect/documentation.html and in particular in: http://help.adobe.com/en_US/Connect/6.0/WebServices/help.pdf (If you have not already seen these resources). Thanks for your continued work on shoring it up and do not hesitate to let me know if I can be helpful in anyway. My goal is always to be supportive, helpful and encouraging. All of my comments should be considered suggestions so please use the ones that are helpful and avoid the ones that are not. Ultimately, it is your contribution and I trust you judgment. Peace - Anthony
Hide
Permalink
David Monllaó added a comment -

Hi Anthony,

Thanks for the links, we used the AC headers authentication system but without SSL installed on the AC server the admin pwd must also be sent decrypted. The best option we've found it's to install SSL on the AC application server and leave the Moodle - AC connection inside the university net to avoid sniffers.

In order to make use of config_plugins (and settings.php if possible) I've read an old thread <http://moodle.org/mod/forum/discuss.php?d=97984> Are there any news about this?

Show
David Monllaó added a comment - Hi Anthony, Thanks for the links, we used the AC headers authentication system but without SSL installed on the AC server the admin pwd must also be sent decrypted. The best option we've found it's to install SSL on the AC application server and leave the Moodle - AC connection inside the university net to avoid sniffers. In order to make use of config_plugins (and settings.php if possible) I've read an old thread <http://moodle.org/mod/forum/discuss.php?d=97984> Are there any news about this?
Hide
Permalink
Anthony Borrow added a comment -

David - Wow, that was almost two years ago. AFAIK, nothing has changed. I do not recall the details, but I ended up being able to get it working; however, it took an extra line of code but was not a big deal. It is just a matter of using get_config and set_config and providing the plugin name. Let me know if you have a specific question about using it but those functions are defined in /lib/moodlelib.php Peace - Anthony

Show
Anthony Borrow added a comment - David - Wow, that was almost two years ago. AFAIK, nothing has changed. I do not recall the details, but I ended up being able to get it working; however, it took an extra line of code but was not a big deal. It is just a matter of using get_config and set_config and providing the plugin name. Let me know if you have a specific question about using it but those functions are defined in /lib/moodlelib.php Peace - Anthony
Hide
Permalink
David Monllaó added a comment -

Good morning Anthony,

Solved changing the plugin attribute of the admin_setting child class called in settings.php, like in http://cvs.moodle.org/moodle/blocks/section_links/settings.php?view=markup

I've uploaded a version with the mentioned issues solved

Show
David Monllaó added a comment - Good morning Anthony, Solved changing the plugin attribute of the admin_setting child class called in settings.php, like in http://cvs.moodle.org/moodle/blocks/section_links/settings.php?view=markup I've uploaded a version with the mentioned issues solved
Hide
Permalink
Anthony Borrow added a comment -

moving to newly created tracker component Block: Adobeconnect

Show
Anthony Borrow added a comment - moving to newly created tracker component Block: Adobeconnect
Hide
Permalink
Anthony Borrow added a comment -

David - Thanks for the updates, they look good. I've added the code to CVS, created the component in the tracker, and give you write access in CVS. Let me know if you think I am overlooking anything. I like to encourage folks to review http://docs.moodle.org/en/Development:Guidelines_for_contributed_code to make sure all the various steps such as M&P, Docs, etc. are taken care of as well. Let me know if you need anything else and thanks again for your patience. Peace - Anthony

p.s. - One other small security suggestion might be to consider using admin_setting_configpasswordunmask instead of admin_setting_configtext for the password field. That way users can unmask (see it if they want) but protect the password from prying eyes.

Show
Anthony Borrow added a comment - David - Thanks for the updates, they look good. I've added the code to CVS, created the component in the tracker, and give you write access in CVS. Let me know if you think I am overlooking anything. I like to encourage folks to review http://docs.moodle.org/en/Development:Guidelines_for_contributed_code to make sure all the various steps such as M&P, Docs, etc. are taken care of as well. Let me know if you need anything else and thanks again for your patience. Peace - Anthony p.s. - One other small security suggestion might be to consider using admin_setting_configpasswordunmask instead of admin_setting_configtext for the password field. That way users can unmask (see it if they want) but protect the password from prying eyes.
Hide
Permalink
David Monllaó added a comment -

Hi,

The admin_setting_configtext to admin_setting_configpasswordunmask change will be the first component commit.

Sorry for bother you again but I've a little question related to CVS branching; that version is for moodle 1.9.x, to begin to work on a 2.0 version I like to tag it as 1.9 block version and continue the 2.0 on HEAD. To tag the actual block version as 1.9 it's just a "cvs tag MOODLE_19_STABLE" in the block root?

Many thanks for all Anthony, you are the one how has patience with us.

Show
David Monllaó added a comment - Hi, The admin_setting_configtext to admin_setting_configpasswordunmask change will be the first component commit. Sorry for bother you again but I've a little question related to CVS branching; that version is for moodle 1.9.x, to begin to work on a 2.0 version I like to tag it as 1.9 block version and continue the 2.0 on HEAD. To tag the actual block version as 1.9 it's just a "cvs tag MOODLE_19_STABLE" in the block root? Many thanks for all Anthony, you are the one how has patience with us.
Hide
Permalink
Anthony Borrow added a comment -

David - No bother at all. I can easily create the MOODLE_19_STABLE branch for you. Usually I check them out separately and work with them individually rather than trying to keep straight which one I am working on in the same directory. For example, I have a separate check out for each version of Moodle and CONTRIB. I have created the files so you should be able to work on them. Let me know if you have any questions or need anything else. Peace - Anthony

Show
Anthony Borrow added a comment - David - No bother at all. I can easily create the MOODLE_19_STABLE branch for you. Usually I check them out separately and work with them individually rather than trying to keep straight which one I am working on in the same directory. For example, I have a separate check out for each version of Moodle and CONTRIB. I have created the files so you should be able to work on them. Let me know if you have any questions or need anything else. Peace - Anthony
Hide
Permalink
David Monllaó added a comment -

Good morning and thanks again Anthony,

I've read http://docs.moodle.org/en/CVS_(developer) and http://moodle.org/mod/forum/discuss.php?d=93365 If I, for example, find and solve an issue present in both MOODLE_19_STABLE and HEAD, I should apply the patch to MOODLE_19_STABLE and tag the file as MOODLE_19_MERGED, if I understood it well, that tag it's only a "remember to apply the patch to HEAD" and it will not be necessary if I apply the patch to both versions. Have I misunderstood something?

Show
David Monllaó added a comment - Good morning and thanks again Anthony, I've read http://docs.moodle.org/en/CVS_(developer) and http://moodle.org/mod/forum/discuss.php?d=93365 If I, for example, find and solve an issue present in both MOODLE_19_STABLE and HEAD, I should apply the patch to MOODLE_19_STABLE and tag the file as MOODLE_19_MERGED, if I understood it well, that tag it's only a "remember to apply the patch to HEAD" and it will not be necessary if I apply the patch to both versions. Have I misunderstood something?
Hide
Permalink
Anthony Borrow added a comment -

David - Those comments really refer to working with Moodle core. In CONTRIB we do not have all of the point branch (1.9.1, 1.9.2, etc.) so it is much simpler. I think folks are fine if they commit their change in the affected branch. If it effects both of them then they merge it into both MOODLE_19_STABLE and HEAD. No need to worry about tagging things in CONTRIB. Peace - Anthony

Show
Anthony Borrow added a comment - David - Those comments really refer to working with Moodle core. In CONTRIB we do not have all of the point branch (1.9.1, 1.9.2, etc.) so it is much simpler. I think folks are fine if they commit their change in the affected branch. If it effects both of them then they merge it into both MOODLE_19_STABLE and HEAD. No need to worry about tagging things in CONTRIB. Peace - Anthony
Hide
Permalink
David Monllaó added a comment -

Ok Anthony, understood. Regards

Show
David Monllaó added a comment - Ok Anthony, understood. Regards
Hide
Permalink
David Monllaó added a comment -

Hi Anthony, having the Adobe Connect block and the Remote learner Adobe Connect module may confuse users. The Remote learner solution is a more customizable integration and, as a module, allows course users to add more than one instance for each course, the block is only a simple course - room synchronization, I think that these are the main differences. I edited the block moodle docs page and the modules and plugins entry to notify the existence of the Adobe Connect module as a more suitable (es ~= sinónimo de customizable no?) integration. Do you think that I should edit something else to clarify what is the difference between the module and the block?

Show
David Monllaó added a comment - Hi Anthony, having the Adobe Connect block and the Remote learner Adobe Connect module may confuse users. The Remote learner solution is a more customizable integration and, as a module, allows course users to add more than one instance for each course, the block is only a simple course - room synchronization, I think that these are the main differences. I edited the block moodle docs page and the modules and plugins entry to notify the existence of the Adobe Connect module as a more suitable (es ~= sinónimo de customizable no?) integration. Do you think that I should edit something else to clarify what is the difference between the module and the block?
Hide
Permalink
Anthony Borrow added a comment -

David - I think as long as the Docs and Modules and Plugins page both have statements indicating that the Adobe Connect Module by Remote-Learner (not to be confused with the Adobe Connect block by you) is a more comprehensive solution. As long as we are transparent with the users and perhaps even steer them to the R-L solution and identify yours as a more limited, simpler alternative then I see no problem with leaving things the way they are. You may even want to provide links to the Docs and M&P pages for the activity module. Peace - Anthony

Show
Anthony Borrow added a comment - David - I think as long as the Docs and Modules and Plugins page both have statements indicating that the Adobe Connect Module by Remote-Learner (not to be confused with the Adobe Connect block by you) is a more comprehensive solution. As long as we are transparent with the users and perhaps even steer them to the R-L solution and identify yours as a more limited, simpler alternative then I see no problem with leaving things the way they are. You may even want to provide links to the Docs and M&P pages for the activity module. Peace - Anthony
Hide
Permalink
David Monllaó added a comment -

Ok Anthony, I've added links to the Remote Learner module M&P and Moodle docs pages, in both moodle docs and modules and plugins block pages. Regards, David

Show
David Monllaó added a comment - Ok Anthony, I've added links to the Remote Learner module M&P and Moodle docs pages, in both moodle docs and modules and plugins block pages. Regards, David
Hide
Permalink
Anthony Borrow added a comment -

Closing all of my resolved issues. Peace - Anthony

Show
Anthony Borrow added a comment - Closing all of my resolved issues. Peace - Anthony

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Moodle. Try JIRA - bug tracking software for your team.