taler-docs

Documentation for GNU Taler components, APIs and protocols
Log | Files | Refs | README | LICENSE

014-merchant-backoffice-ui.rst (4130B)

      1 DD 14: Merchant backoffice UI
      2 #############################
      3 
      4 
      5 Motivation
      6 ==========
      7 
      8 The merchant should have a user-friendly way to manage the merchant
      9 backend, which can currently only be done via a HTTP+JSON RESTful API
     10 (:doc:`../core/api-merchant`).
     11 
     12 
     13 Security Architecture
     14 =====================
     15 
     16 Either (simple deployment):
     17 
     18   Internal auth (via API key, user directly downloads SPA, asked to enter
     19   API key).  See: https://bugs.gnunet.org/view.php?id=6731
     20 
     21   API token/key is persisted (by SPA) in local storage of browser until
     22   you explicitly logout.
     23 
     24 Or (large company with existing authentication infrastructure):
     25 
     26   External auth:
     27 
     28   1. Login flow via reverse proxy for authentication:
     29 
     30      BROWSER -> AUTH-PROXY -> (likely) redirect to login server
     31 
     32   2. AUTH-PROXY may redirect to login server, passes authentication token
     33      via URL param when redirecting back to the AUTH-PROXY for the SPA
     34      download
     35 
     36      BROWSER -> AUTH-PROXY -> SPA (download HTML/JS from backend)
     37 
     38   3. Running SPA:
     39 
     40      SPA-in-BROWSER -> AUTH-PROXY -> BACKEND
     41 
     42      https://backend/instance/foo/
     43 
     44      - Browser shows login dialog (401 Unauthorized, say).
     45 
     46      - AUTH-PROXY is happy, allows download of HTML.
     47 
     48      - All requests from SPA are then automatically auth'ed because the
     49        browser KNOWS already how to bypass the auth-proxy (token
     50        validation, etc).
     51 
     52 
     53 User stories
     54 ============
     55 
     56 Story #1: Login
     57 ---------------
     58 
     59 1. User loads SPA at say https://backend/instance/$FOO/
     60 
     61 2. SPA asks for authorization IF an API key is specified/required by the
     62    merchant backend for the respective instance.
     63 
     64    Note: we have several authorization methods:
     65 
     66    - HTTP ``Authorize`` header with pre-shared key
     67 
     68    - (maybe?) username / password
     69 
     70    - (maybe?) theoretically: TLS client certificates (maybe much later)
     71 
     72    Additionally, the user may specify which instance to log into, as
     73    different instances may use different credentials.  So the SPA needs to
     74    fetch the list of instances.
     75 
     76 3. Special case: If there are no instances, the ``default`` instance MUST
     77    be used, and the login should immediately move on to the ``setup``
     78    (default) instance dialog, forcing the user to setup the default
     79    instance upon first login.
     80 
     81 4. After login, we (somehow) need to persist the login data in the SPA.
     82    Local storage or just global variable in the JS?  Local storage may be
     83    better to survive page reload, right?
     84 
     85    Q: How does the SPA know about the base URL?  In the LibEuFin UI, it's
     86    part of the login page.
     87 
     88    A: Just use relative URLs to its own location? => Possible, but might
     89    now always be the case
     90 
     91    => Could use relative URL by default, maybe have a field to allow user to
     92    override? => Makes sense.
     93 
     94 5. LOGOUT button to reset state and go back to login page.
     95 
     96 6. "Change instance" drop-down, to change instance without having to log
     97    in again IF the credentials are the same?
     98 
     99 
    100 Story #2: Manage instances
    101 --------------------------
    102 
    103 This involves only the ``default`` instance owner.
    104 
    105 Management operations include:
    106 
    107 - creating an instance (including in particular merchant bank accounts)
    108 
    109 - deleting an instance (with extra confirmation)
    110 
    111 - updating an instance (change in bank accounts)
    112 
    113 Q: Do we have some separate "admin login" to manage instances?  Who is
    114 actually allowed to manage instances?  LibEuFin has some permissions
    115 system for this.
    116 
    117 A: Default instance owner can manage instances. But, there is a
    118 complication: *credentials* for all instances are managed in nginx
    119 configuration, NOT via the REST API.  So default instance owner can create
    120 new instances, but access control MUST be configured by the sysadmin.
    121 
    122 
    123 Story #3: View orders and their status, grant refunds
    124 -----------------------------------------------------
    125 
    126 - list all orders (by date, by payment status, etc.)
    127 
    128 - for paid orders, view details (show contract, show already granted
    129   refunds, trigger refund)
    130 
    131 
    132 Story #4: Manage inventory
    133 --------------------------
    134 
    135 - add product to inventory
    136 
    137 - update stock (increase available stock)
    138 
    139 - change product description / price / etc.
    140 
    141 - delete products from inventory