user shell be able to register herself at deepamehta

[JuergeN]

We need a plugin so that a user can register herself to deepamehta. Ideally the user enters her preferred username and her email address and then gets an email for confirmation. The password must be changed at first login and be checked for sufficient complexity. The user TopicType? should be enriched with a profile incuding:

• username
• a picture (optional)
• first name (optional)
• last name (optional)
• nick name (optional) - see #42
• mail address (checkbox for visible/invisible ACL)
• ...

A registration through OAuth would be an additional alternative.

[Malte]

Hy dear JuergenN, I might be able to help out here in the upcoming months (in the latter weeks of February).

Ok, so far I could agree on the following core requirements (1st version):

• identify users/people upon registration via a valid (per-mail-confirmed) mailbox either/or via
  • utilising/depending on the dm4-mail plugin or
  • via an openID-Service provider
• "block" the account until "verified" via the confirmation-link sent per mail
• provided password must match a certain complexity (simple 1 factor authentication)
• the "admin" (superuser) should be able/have the permission to
  • block" certain accounts again (preventing them from gaining access)
  • change the password of a user-account
• the user should have the possibility to enter an additional nickname

Sums up to extending a "user" in dm about "mailbox" and "nickname" and "status" (active/blocked). Other fields I see optional for the moment too, since these could also be extended interactively by amdministrative-users of the plugin for their purpose and/or we just relate a "person" to a "username", use it's primary mailbox and extend username just about the field "nickname" and "status"?

Questions so far:

• if a nickname is not set? resp. does the registration form contains both "username" and "nickname" or when shall this be set?
• i guess it would be totally fine to achieve this functionality with a plugin comin in a seperate UI redirecting user to the webclient after login?
• this seperate UI for registration should then also handle the complete login procedure
• in the first version, there won't be a "password reset"-functionality, OK?

OAuth is afaik a complete authentication protocol and goes far beyond registration/identification of users upon registration and as far as the dm4-webclient is concerned is currently not supported. What I find attractive is providing registration by means of OpenID. It just returns you the mailbox and an OpenID Value (later used as the username for login) from a third-party service provider. I've recently seen ​http://rvl.io (something of a HTML/JSS/CSS prezi) making it wonderfully uncomplicated through implementing just exactly that.

First outlook:

Identification/registration of a person per mailbox is exactly what one needs as core-functinality to run a simple "sign up for a petition"-tool (not necessarily through creating user accounts) - i find this interesting in means of a possible extension of this plugin but would leave it up to the developer. This wouldn't be a core-requirement for the 1. version but it may be easily reached within the scope of developing this functionality anyways, I think.

I will let sink this in a bit, but yeah, let's continue to nail this down. Just wanted to share my thoughts about this for the moment.

[Malte]

Not to forget, another core requiremnt, which is a bit trickier and possibly undecidable:

• which workspace to assign the new user as a "member" by default?

And I would also be happy to discuss other questions this plugin will open-up. In particularly what it means being a user in a collaborative environment, starting with simple questions like:

• how does a user relate to all topicmaps/personal views in a deepamehta-installation cause afaik there are no personal topicmaps in such, every user sees all maps of all users.
• how does a user relate to a workspace, resp. what is the concept of a workspace right now?

But maybe it would be better to discuss certain concept related things in the wiki and keep this ticket just for the requirements-listing of version 1). And I shall also notify list about this opportunity for feature-discussion.

Cheers.

[JuergeN]

• if a nickname is not set? resp. does the registration form contains both "username" and "nickname" or when shall this be set?

I think the nickname should be set at first registration. If nickname is not set, user would appear with username.

• i guess it would be totally fine to achieve this functionality with a plugin comin in a seperate UI redirecting user to the webclient after login?

sure.

• this seperate UI for registration should then also handle the complete login procedure

agreed.

• in the first version, there won't be a "password reset"-functionality, OK?

Fine for me. But maybe for v1 we could resend the password by mail at least.

OAuth is afaik a complete authentication protocol and goes far beyond registration/identification of users upon registration and as far as the dm4-webclient is concerned is currently not supported. What I find attractive is providing registration by means of OpenID. It just returns you the mailbox and an OpenID Value (later used as the username for login) from a third-party service provider. I've recently seen ​http://rvl.io (something of a HTML/JSS/CSS prezi) making it wonderfully uncomplicated through implementing just exactly that.

Yes, you are right - I was confusing OAuth and OpenID. The letter is what I ment for now.

[JuergeN]

• which workspace to assign the new user as a "member" by default?

Some time ago I wrote about "Private - Shared - Public" https://trac.deepamehta.de/wiki/JuergeN/Philosophy :

Any content can either be private, shared or public. Private content is content only the creator can see and edit. Shared content is content that is shared with other people (a group). It makes sense to differenciate if the content is privately shared or commonly shared.

Privately shared content is content that the owner shares with other people she invites. The decision about who she shares the content with remains her private decision.

Commonly shared content is content the creator shares with other people who may then themselves decide with whom else they want to share the content (distributed content sharing).

Public content is content that is available to / shared with everyone.

Shared content can be shared read only or read/write ( = edit, delete).

So I wish we had these four types of workspces:

• private (for the owner's eyes only) = private
• privately shared (creator/owner may invite other users) = shared
• commonly shared (any users may invite other users into the goup) = common
• public (all content is shared with everyone) = public

The private and the public workspace would exist by default (one private per user and one public per deepamehta-instance) and a user would always be assigned to her private workspace and the public workspace.

I addition the user should be able to create new workspaces which could either be shared or common.

[Malte]

Sorry for the delay and the "funkstille", I now plan to realize the first milestone at the end of this month (March) and I hope I can make it. At last, I am very opportunistic of being able to dedicate me to this task by the beginning of April.

in the first version, there won't be a "password reset"-functionality, OK?

You wrote:

Fine for me. But maybe for v1 we could resend the password by mail at least.

But since DM doesn't know the password, we cannot resend it. So providing users some kind of "password reset" functionality would be the more obvious thing to do, but that still needs to be done "the right way" (let's say 2-factor authentication at least).

And thanks for sharing your notes on "levels of sharing infos" again here. When writing my last comment I was more thinking about a nearby way to just pull through deepamehta's core concept of "personal views", even before getting the public/private relation of contents right.

Say: I wouldn't mind if all contents where still publicly readable, if I just wouldn't need to bother with the topicmaps/views of other users after I am logged in.

But after thinking about it for a while, this is probably not the best step to take right now, since more fundamental paths need to be laid out first and those may render my concern unproblematic.

I just thought it may be way more in reach for us now to realize personal views on public contents first and personal contents in public views then.

Maybe the question which gets us 2 steps forward here might be something like: "What would be the easiest way to realize e.g. private "Notes"? (because a "Note" is an exemplary TopicType? which might all workspaces will share) but any user wants to take private ones first and share them in other contexts later.

I set up a wiki page at https://trac.deepamehta.de/wiki/PrivateNotes if someone would likes to share his or her thoughts on the "private Notes" branch of thoughts.

Cheers!

[jri]

As you said, Malte, the whole "Privacy" aspect does not fit this ticket's original topic.
Thanks for creating the PrivateNotes? wiki-page!
I extended that with my view of how privacy could be realized in DM. However, I like to discuss that not in the wiki but in its own ticket. This would be more focused and more findable. For that purpose I created #419 (Privacy) and copied our wiki-input there. You could consider to delete the wiki page. Thank you for your input!

[jri]

I deleted the wiki page and hope this is OK for you.
The Privacy topic is very important and is much more visible now as a ticket.

[Malte]

Since we talked about this, let's call it "Sign up"-plugin, here's the last update on 1.0 spec:

• nickname is going to become part of the 4.2 core (see #42)
• blocking an existing "user account" (denying access without deleting account) is going to be part of the 4.2 core (see #462)

The "dm4-sign-up"-module should handle the registration process in at least the following way:

• enrich any "User account"-topic about (a) "Person" or (b) "Mailbox"
• validate any given username for uniqueness, before a "registration request" is created
• create a "Registration Request" (composed of types _Username_ und _Password_ as aggregated child topics) for each newly requested account with another type storing some uuid generated "Token" (the token is kind of a secret identifying this registration process)
• send a mail to the mailbox with a confirmation link
• serve a "/sign-up/confirmation/<token>" interface taking any request on it with a <token>, triggering the final "user account" creation process and deletion of the intermediary "registration request"
• activate any "confirmed user account" by default

Another idea discussed at latest dev meeting which looks (a) faster to implement and (b) doesnt rely on dm4-useraccounts at all but instead on third-party-auth-providers, is the idea of a "dm4-sign-on"-module (#463), implementing deepamehta-login as a simple identity-consumer (in terms of OpenID).

Probably I've forgottone something, but we'll see when we're at it.

Edited: Added link to the ticket on the federated "dm4-sign-on"-approach to this comment + ticket.

[Malte]

Ticket Scope DONE:

• provide a custom (form-based) gui for the self-registration process (with yet very trivial password, username and mailbox validation) but with interactively rendered "notifications"
• aggregated model: after installation of this plugin a "Person" relates to a "User Account", so we would be using the "E-Mail Address" of a "Person" (for sending mails to a user)
• validate any requested username (AJAX-Style) and deny doublettins

Ticket Scope TODO:

• model "Registration request" and "Confirmation Token" (was this just to validate a mailbox and prevent spam registrations)
• integrate sign-up plugin with dm4-mail
• provide a simple custom (form based) login-dialog (with link to registration dialog and vice versa)

[Malte]

Since now, with the new wikidata-plugin, I have a case for this to be done, I wanted to finish a minimal version of this idea but ran into the follpwing problem.

As proposed by you, I now implemented this plugin the way that it sends the Account-Creation-Request as a HTTP GET Request (to circumvent the error which would be thrown by DM when the setup is like: "write_requires_login=true").

Now, the user-account topic could not be created because the "username" is unknown to DM (probably because of a missing HTTP Session/ClientState??) - while the username is actually known to my plugin-implementation (in the scope of the method) in which I am executing the dms.createTopic()-call.

The goal is, obviously, the "User Account"-Topic in the end has to have set it's "username" as "owner" and "creator". To achieve that I can now imagine to

• (A) set these correct username manually after the topic was created,
• (B) pass the "username" on to the createTopic()-call directly (which might be prove handy in other scenariios too, e..g plugins connecting third party services for users),
• (C) use some "createUserAccountTopic()"-Service call provided by the ACL-Plugin-Service.

Maybe there is a qucik solution to this and I would very much appreciate any help here.

Thanks & Nice greetings!

[Malte]

Please check this again. Thank you very much.

[Malte]

The final things to be implemented to reach into the scope of this ticket with the dm4-sign-up plugin would be now:

• model "Registration request" and "Confirmation Token" (was this just to validate a mailbox and prevent spam registrations)
• integrate dm4-sign-up plugin with dm4-mail

But for the moment, even if there is all that addtional work done, #665 must be solved.

Source code: ​https://github.com/mukil/dm4-sign-up

Thats the state of the art.

[Jörg Richter]

Fix: create User Acount without session (#665).

When a User Account topic is created (via dms.createTopic()) while no session exists (that is no user is logged in) no exception occurs. The created User Account topic (and its child topics) will have no creator/owner/ACL information. It's up to the developer to set these manually afterwards.

See #405.
See #665.

• Changeset: 9795b81cfed1e7e57c4d6db806a0d2567c32964b
• URL: ​https://github.com/jri/deepamehta/commit/9795b81cfed1e7e57c4d6db806a0d2567c32964b

[Jörg Richter]

Fix: create User Acount without session (#665).

When a User Account topic is created (via dms.createTopic()) while no session exists (that is no user is logged in) no exception occurs. The created User Account topic (and its child topics) will have no creator/owner/ACL information. It's up to the developer to set these manually afterwards.

See #405.
See #665.

• Changeset: 9795b81cfed1e7e57c4d6db806a0d2567c32964b
• URL: ​https://github.com/jri/deepamehta/commit/9795b81cfed1e7e57c4d6db806a0d2567c32964b

[jri]

Meanwhile the sign-up plugin works as intended (#816).