Google docs repository improvements

Google docs repository improvements

by Matt Petro -
Number of replies: 13

I've been tasked with adding some features to the google docs repository that meet specific needs for our site.  The changes are summarized below and I'd like to know if these would be welcome upstream:

-  Include collection support (basically folders) in the repository

-  Allow links to documents, rather than just copying documents to moodle.  A link points to the html version of a published document.  The repository does the publishing automatically when a link is created.

-  Switch to OAUTH authentication so that the warning about untrusted sites isn't displayed to users.  Also, OAUTH is recommended by google. (Signed AuthSub would also get rid of the warnings, but google seems to be moving away from that)

-  Allow specification of a hosted domain, so that it's easy to login to e.g.  @yourschool.edu  hosted accounts

-  Show the google account that's in use in file picker.  Otherwise it can be confusing with multiple accounts, as people may have both a personal and a hosted account.

-  Allow other types of content (images, user content, etc)

 

These changes are implemented right now as a proof of concept, and I'd like to know if any or all of them would be welcomed into the moodle base code.   I found the moodle googleapi.php and liboauth.php to be a little simplistic, and chose to use the Zend/Gdata, and Zend/Oauth stuff instead, as switching from AuthSub to OAUTH meant rewriting googleapi.php anyways.   The code could be reimplemented using custom classes if need be, although I think the Zend/Gdata stuff is self-contained enough to be a useful addition and is actually in 2.1, although unused.  Zend/Oauth would have to be added.  lib/zend has a note contained in it not to use the libraries outside /webservices/, so I'm a little unsure.

Anyways, any thoughts on these features?  I've attached a screenshot showing the collection support.

-matt

 

Attachment collections.png
Average of ratings: -
In reply to Matt Petro

Re: Google docs repository improvements

by Jason Platts -

Although I'm not so interested in the repository side of things, I am really interested in using OAuth to connect to the Google Docs API as I'm just about to write a module that needs this (AuthSub won't work with want I want to do).

I too noticed the note about the Zend library and not using outside of web services, so had intended to write a standalone class.

So I'd be interested to see:

  1. If it's OK to use Zend and get Zend OAuth added to core
  2. If  OAuth support for Google could be added to core to replace the existing AuthSub (If there's a tracker issue for this I'll happily vote!)
Average of ratings: -
In reply to Jason Platts

Re: Google docs repository improvements

by Dan Poltawski -

Hi Matt/Jason,

I wrote the Google Plugins in core, and actually the Google API's have evolved significantly since then.

At the time I looked Zend libraries and was put off from their massive size (increasing the bloat/security risk for Moodle) for very little gain. I think at that time Google Docs API only supported AuthSub & ClientAuth auth mechanisms. I went for AuthSub because:

  1. I believed it encouraged the correct web practices (only putting your google password in to Google rather than into third party sites which can do as they liked with them)
  2. It was much lighter weight to setup (its nice even now that admins only need to enable the plugin to support Google integration, despite the minor alert).

But now I agree that Google OAuth support looks like it might be the right way forward, and it solves the first of my concerns with clientauth. I think it is more heavy weight to setup though (not looked at this for a while), so it would be kinda cool if we could make Moodle retain the ease of setup, whilst allowing admins who will do all the OAuth setup have that power.

I've not looked at Zend for a while, do you have any idea how much of Zend we have to integrate to get the Google Libraries?

Average of ratings: -
In reply to Dan Poltawski

Re: Google docs repository improvements

by Matt Petro -

> I think it is more heavy weight to setup though

This is true in a sense.  Both methods require registration with google, but OAUTH also requires a secret to be configured in moodle.  Zend  supports both, so we could use (unsigned) AuthSub as a fallback if OAUTH isn't configured.

 

As for how up to date the Zend libraries are,  I'm not sure.  For what I've needed they have worked fine, and seem preferrable to manipulating XML/namespaces/.. directly with php.   I don't feel strongly about this, and would be happy to help rewrite lib/googleapi.php if that's what we decide.

 

Here's some references:

http://code.google.com/apis/gdata/docs/client-libraries.html

http://code.google.com/apis/gdata/docs/auth/oauth.html

Average of ratings: -
In reply to Matt Petro

Re: Google docs repository improvements

by Dan Poltawski -

The code could be reimplemented using custom classes if need be, although I think the Zend/Gdata stuff is self-contained enough to be a useful addition and is actually in 2.1, although unused.

Sorry I only just noticed this point. How up to date is it, is it keeping track with the Google API improvements?

Average of ratings: -
In reply to Matt Petro

Re: Google docs repository improvements

by Bob Puffer -

I'm chest-deep into the Google API and could offer the following reflections:

  1. Google's provisioning and docs API evolves almost daily, important to always have tabs open and checking on changes, staying at the current or even the "labs" version of the API
  2. Zend, IMO is out-of-date and has shown little interest in keeping up with the Google API changes
  3. IMO for Google Apps for Education domains its best to use 3-legged OAuth (recently renamed, "Google Apps administrative access to impersonate other domain users") to maintain security while easing the interchange between Google and Moodle
If anyone is interested and thinks it can be of benefit to their organization, I've posted code for our Google Apps for Ed integration block (called Morsle) out on github (bobpuffer, Moodle-Morsle_block) which contains a lot of the low level functions that Zend should have provided.  It is currently targeted at 1.9 but would need only a few changes (to block and $DB call structures) to use in 2.x.  Once again, this is primarily targeted at Google Apps for Ed domains and is in production at our school.  Feel free to adapt as needed.
Average of ratings: -
In reply to Bob Puffer

Re: Google docs repository improvements

by Matt Petro -

Thanks, I'll have a look at the code.

I think you have 2 and 3-legged oauth reversed;  I am using 3-legged.   2-legged OAUTH requires domain administration rights, which we don't have.

Average of ratings: -
In reply to Matt Petro

Re: Google docs repository improvements

by Bob Puffer -

I am sorry, you're right and I mis-spoke.  2-legged is exactly what I meant, leaving the the third leg (user) out of the transaction.

Average of ratings: -
In reply to Bob Puffer

Re: Google docs repository improvements

by Matt Petro -

> Zend, IMO is out-of-date and has shown little interest in keeping up with the Google API changes

Which API's have you had problems with?   For the repository plugin, only oauth and Documents List API are needed.

Average of ratings: -
In reply to Matt Petro

Re: Google docs repository improvements

by Bob Puffer -

Well, its likely I've taken my integration of Google docs further than Moodle's repository API and that's why I have trouble -- it entails an integration with Google Apps.  As an aside, I pretty much have trouble with Moodle 2.x's repositories in general (if you've caught any of my other flaming posts) as they're, IMO, mis-named and should actually be called more like "staging areas".  When you get into dealing with exporting of spreadsheets, etc. you have a number of issues with Zend.  You also encounter an inability to deal well with the current (for the last couple years) trend of Google to constantly re-direct calendaring requests using OAuth to a site that only accepts ClientAuth.  To me, Zend was bloated, unnecessarily difficult and wasn't going to keep up with the current versions of the APIs (as is evidenced when you search on "Google API Zend" (you get a boatfull of issues due to obsolescence).  

Average of ratings: -
In reply to Matt Petro

This forum post has been removed

The content of this forum post has been removed and can no longer be accessed.
In reply to Deleted user

Re: Google docs repository improvements

by Bob Puffer -

Whatever you do in this area its pretty clear it won't last long unless its supporting OAuth2 -- Google's made it awfully clear that's their direction.  I'd also like to see optional support for 2-legged OAuth.  Its what we use.  We provision the accounts through Google Apps and retain rights to act on behalf of the college in managing the resources stored there without intentionally violating privacy.  There are MANY third-party plugins that would like to have 2-legged OAuth available to faciliate their needs.

Average of ratings: -
In reply to Bob Puffer

This forum post has been removed

The content of this forum post has been removed and can no longer be accessed.
In reply to Matt Petro

Re: Google docs repository improvements

by Greg Rodenhiser -

In your post you mentioned that a signed AuthSub could also get rid of the security warning message brought forward by Google when using the GoogleDocs repository.  Is it possible to use a signed AuthSub in Moodle 2.2.x?  If so, how?  Thanks in advance!!

Average of ratings: -