mahara-contributors team mailing list archive

[Aaron Wells <1620879@xxxxxxxxxxxxxxxxxx>]

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