See https://github.com/agwells/mahara/tree/mobile for my work in progress on this.
The following API changes need to be included (hopefully these can squeak into 16.10.0). Most of these are cribbed from how the functionality works in Moodle (because our Webservices module is port of the Moodle webservices module): 1. Addition of the two token-generation scripts, one REST-based for the in-app-form scenario; the other a standard webpage for the embedded- iframe SSO scenario. 2. Add a "shortname" to WS service groups, that the token generation scripts can use to unambiguously refer to which service group they want a token for. 3. Use the presence or absence of a "component" value for WS service groups, to indicate whether the service group was created by a plugin, or manually created by a human. The "component" should indicate which plugin created them. 3a. Block the UI from adding/removing functions from plugin-created service groups. 3b. Update all the "example" service groups that currently ship with Mahara, so that they no longer have a "component" value 4. Implement any necessary functions and/or service groups for the mobile app. (The clean way of doing this would be to make the app do everything through the new webservices system, and get rid of the old /api/mobile directory. The quick-and-dirty way of doing this would be to create a function in the new webservice, for generating the tokens used by /api/mobile. [So yes, that would mean the app gets a token for the *new* webservices, then uses that to get a token for the *old* webservices.]) 5. Determine the access control; which users are allowed to self- generate webservice tokens? Moodle does this via its capabilities system, which there is no direct equivalent of in Moodle. The current webservices permissions don't exactly work for this. See follow-up note for more details. 6. Give users the ability to inspect and cancel their self-issued webservices tokens. (This mainly means, changing the permissions and navigation menus for webservice/apptokens.php, which is currently an admin-only script that handles this behavior.) -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1620879 Title: Allow users to self-issue webservice access tokens Status in Mahara: New Bug description: For the generation 2 Mahara mobile app ( https://github.com/maharaproject/mahara-mobile ), we want users to be able to generate the access tokens they need via the app itself, rather than the current process where users have to log in to Mahara in a web browser, go to their account settings page, scroll to the bottom and manually create an access token (typing in its value themselves), then launch the mobile app and write that same access token into the mobile app. Instead, we envision a process the same as the Moodle Mobile app. The user is presented with a username/password field, they enter their credentials there, and the app then does the dirty work of talking to the Mahara server, requesting the access token, and storing it. In order to support SSO options, there also needs to be an alternative flow, where the app opens an embedded iframe that displays the Mahara login form, and returns the access token value back to the app when done. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1620879/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~mahara-contributors Post to : [email protected] Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
