Differences

This shows you the differences between two versions of the page.

--- mantisbt:passwordless_protected_access [2007/04/14 15:37] – created vboctor
+++ mantisbt:passwordless_protected_access [2011/11/16 07:38] (current) – The page rendering was broken (maybe since new PHP version on mantisbt.org). Added new line to fix it at end of file. atrol
@@ Line 1: / Line 1: @@
 ====== Passwordless Protected Access ======
-> 1. Does the user get a snapshot or access to future changes as well.
+===Overview===
-The current state.
+A user can be given a link of the form http://mantis.company.com.au/view.php?id=123&key=987tyjkhcgwip2uy523hriu and then be able to view and/or edit the task without a separate login. This is particularly useful when you want to email a link to a person without creating an account for them or without asking them to login (which might be too much effort for some customers).
-> 2. What access does the user get when accessing this issue?  For
+===Implementation===
-> example,
-> does the user then get access to private notes?
-In our current implementation no. But that could be an option I
+A unique key must be generated for every bug. Two options are possible:
-guess. We use private notes for internal conversations we don't want
-our customers to read.
-> 3. Does the user only have read-only access to the issue?
+(1) generate random key when creating a bug record. Update old bugs through some conversion script.
+(2) create a hash based on the bug id plus some constant random key. That constant key must be different for every Mantis implementation. (Perhaps the feature is switched off until this key is generated.)
-For us yes, (but they can add notes). We don't want customers all
+Advantages of (1): shorter URL since you don't need to add the "id" parameter.
-increasing priority to "extremely high". Sounds like another
+Advantages of (2): no changes to the db schema
-candidate for some preferences for the Mantis admin to choose.
-> 4. What configuration options are going to be used to implement this
+We don't need to set a login cookie at all, since this is effectively an alternative access control.
-> feature?
-I need to read some more Mantis code to see how this works.
+===Configuration options===
-> 5. What are the suggested database changes?
+[x] enable bug access URL
+  [x] allow edit of bug
+  [x] allow adding notes
+  [x] show private notes
-The main one is that we need a random key assigned to each bug. Then:
+=== Example ===
-http://mantis.company.com.au/task.php?key=987tyjkhcgwip2uy523hriu
-will take you directly to the appropriate page. The way we use that
-is to put that link into outgoing confirmation emails. Customers can
-click on the link to be taken directly to the appropriate task, see
-the (public) notes and history and make another note. It is very
-important (for us) that this page be highly customised. We want only
-a subset of fields (for instance we don't want them to know who is
-assigned to the task, or what priority we decide to set it) and we
-want a page design which looks pretty.
 Here is an example which we were using for testing a while back:
@@ Line 43: / Line 30: @@
 http://squish.ish.com.au/t?i=4691&w=qxn0CoSqgIi0NDZ96VSl
-===== Some Ideas =====
+=== Page view ===
-  * At the moment we implement anonymous access by creating a shared account for it, then automatically authenticated users that don't login as this Mantis user.  This provides consistency in determining what the users can see and do.  This also gives the administrator/managers the ability to decide what an anonymous user can do for each project.  We should do the same for this kind of access.  Once a user visits a link we authenticate him as this user, but we don't setup any cookies.  Hence, if the user navigates to other pages of the installation the user will get access denied.  Such kind of authentication is done in scripts like the SOAP interface.
-  * In the case where a customer gets a link with the passphrase for a private issue.  The customer should get access to the issue even if the account used typically doesn't have access to private issues.  So the code that checks access to the issue as a whole will have to keep this into consideration.
+The display of the bug should be customisable independently of the regular bug view page. This allows the admin to remove from the view certain fields (eg. who the bug is assigned to), style the page in a more corporate way and also remove links which make no sense (eg. advanced view).
-  * If a logged in user (i.e. viewer, developer, manager or administrator) clicks on a link that has the passphrase, then the passphrase access should override the default access for this user.  Hence, the user can preview what non-registered users will see when they visit the same page.