Merge pull request #59 from privacybydesign/dockerize

Dockerized docs

.dockerignore

@@ -1,2 +1,5 @@
-*/node_modules
+**/node_modules
 *.log
+**/.git
+**/.DS_Store
+website/build

.gitignore

@@ -7,8 +7,8 @@ lib/core/MetadataBlog.js
 
 website/translated_docs
 website/build/
-website/yarn.lock
 website/node_modules
 website/i18n/*
 
+yarn.lock
 .vscode/

Dockerfile

@@ -1,10 +1,11 @@
-FROM node:18
+FROM node:21 as build
 
 WORKDIR /app/website
 
-EXPOSE 3000 35729
 COPY ./docs /app/docs
 COPY ./website /app/website
-RUN yarn install
+RUN yarn install --immutable --immutable-cache --check-cache
+RUN yarn build
 
-CMD ["yarn", "start"]
+FROM joseluisq/static-web-server:latest
+COPY --from=build /app/website/build/irma-documentation /public

docker-compose.yml

@@ -1,18 +1,10 @@
-version: "3"
+version: '3.7'
 
 services:
-  docusaurus:
-    build: .
+
+  app:
+    build:
+      context: .
+      dockerfile: Dockerfile
     ports:
-      - 3000:3000
-      - 35729:35729
-    volumes:
-      - ./docs:/app/docs
-      - ./website/blog:/app/website/blog
-      - ./website/core:/app/website/core
-      - ./website/i18n:/app/website/i18n
-      - ./website/pages:/app/website/pages
-      - ./website/static:/app/website/static
-      - ./website/sidebars.json:/app/website/sidebars.json
-      - ./website/siteConfig.js:/app/website/siteConfig.js
-    working_dir: /app/website
+      - 3000:80

docs/api-irma-server.md

@@ -137,7 +137,7 @@ The response may contain the following fields:
    * `"UNMATCHED_REQUEST"`: proofs do not correspond to a specified request
    * `"MISSING_ATTRIBUTES"`: proofs do not contain all requested attributes
    * `"EXPIRED"`: Attributes were expired at creation time
-* `disclosed`: List of [attributes disclosed](https://godoc.org/github.com/privacybydesign/irmago#DisclosedAttribute) by the user. The array structure mirrors that of the [session request](session-requests.md#disclosure-requests) that started the session: the i-th item of the outer array is a conjunction of attributes satisfying the i-th outer conjunction of the session request. (*Note*: if the session was started with a legacy, pre-[condiscon](condiscon.md) session request, then this array structure has a different legacy structure; see the [legacy documentation](/docs/v0.2.0/api-irma-server#get-session-requestortoken-result))
+* `disclosed`: List of [attributes disclosed](https://godoc.org/github.com/privacybydesign/irmago#DisclosedAttribute) by the user. The array structure mirrors that of the [session request](session-requests#disclosure-requests) that started the session: the i-th item of the outer array is a conjunction of attributes satisfying the i-th outer conjunction of the session request. (*Note*: if the session was started with a legacy, pre-[condiscon](condiscon.md) session request, then this array structure has a different legacy structure; see the [legacy documentation](/v0.2.0/api-irma-server#get-session-requestortoken-result))
 * `signature`: The full attribute-based signature in case of `"signing"` sessions
 * `error`: Error message in case of failure
 

docs/chained-sessions.md

@@ -5,8 +5,8 @@ title: Chained sessions
 Since version 6.1.0 of the [Yivi app](yivi-app.md) and 0.8.0 of the [IRMA server](irma-server.md), multiple [IRMA sessions](what-is-irma.md#session-types) may be chained together by the requestor into a single flow. After the Yivi app user has started the first session (for example, by scanning a QR code), she then passes through multiple session screens, as shown here. In this example, the requestor uses a disclosure session to retrieve the user's name and then immediately afterwards issues that into a new credential.
 
 <div class="center" style="margin-bottom: 1em">
-  <img src="/docs/assets/chain-disclosure.png" style="width: 35%;" alt="disclosure-flow" />
-  <img src="/docs/assets/chain-issuance.png" style="width: 35%; margin-right: 3em" alt="issuance-flow"/>
+  <img src="/assets/chain-disclosure.png" style="width: 35%;" alt="disclosure-flow" />
+  <img src="/assets/chain-issuance.png" style="width: 35%; margin-right: 3em" alt="issuance-flow"/>
 </div>
 
 The IRMA server enables this by sending the session results of the intermediate sessions in the chain to a server chosen by the requestor, which can process the session results and respond with a session request for the next session in the chain.

docs/condiscon.md

@@ -24,7 +24,7 @@ An [IRMA disclosure session](what-is-irma.md#session-types) is started by a veri
 
 <!--DOCUSAURUS_CODE_TABS-->
 <!--Yivi app-->
-<img src="/docs/assets/pre-condiscon.png" class="ss" alt="pre-condiscon" />
+<img src="/assets/pre-condiscon.png" class="ss" alt="pre-condiscon" />
 <!--Session request (old format, JSON)-->
 ```json
 {
@@ -51,7 +51,7 @@ An [IRMA disclosure session](what-is-irma.md#session-types) is started by a veri
 
 <!--DOCUSAURUS_CODE_TABS-->
 <!--Yivi app-->
-<img src="/docs/assets/condiscon.png" class="ss" alt="condiscon" />
+<img src="/assets/condiscon.png" class="ss" alt="condiscon" />
 <!--Session request (condiscon, JSON)-->
 ```json
 {
@@ -179,7 +179,7 @@ The `irma server` of version `0.3.0` and up is:
 - Backwards compatible with the old session request format, i.e. with old IRMA requestor applications. New session request JSON objects are recognized as such by the presence of their `@context` property; if this is absent the request is interpreted as a pre-condiscon IRMA session request.
 - Backwards compatible with old Yivi apps, as long as the condiscon feature is not used in the session (i.e., all inner conjunctions contain exactly 1 attribute).
 - [This `irmago` unit test](https://github.com/privacybydesign/irmago/blob/condiscon/irmago_test.go#L259) shows how pre-condiscon session requests are converted, by asserting equality of pre- and post-condiscon session requests, for all three session types.
-- The documentation of the pre-condiscon session format can be found on the [session requests](/docs/v0.2.0/session-requests) page.
+- The documentation of the pre-condiscon session format can be found on the [session requests](/v0.2.0/session-requests) page.
 
 The new Yivi app is backwards compatible with the old session request format, i.e. with old `irma server`s, *except* in case of signature sessions (see below).
 

docs/irma-protocol.md

@@ -42,9 +42,9 @@ Generate these using `java -jar path-to-plantuml.jar -tsvg *.puml` in docs/asset
 
 <!--DOCUSAURUS_CODE_TABS-->
 <!--Pairing disabled-->
-<img src="/docs/assets/session-no-pairing.svg">
+![Pairing disabled](/assets/session-no-pairing.svg)
 <!--Pairing enabled-->
-<img src="/docs/assets/session-pairing.svg">
+![Pairing enabled](/assets/session-pairing.svg)
 <!--END_DOCUSAURUS_CODE_TABS-->
 
 ### Further reading

docs/issuer.md

@@ -13,7 +13,7 @@ In IRMA, information on all issuers, their credentials and the contained attribu
 Generally, the process of becoming an IRMA issuer looks as follows. These steps are documented in detail in the sections below.
 
 1. Collect all relevant information on your issuer, its credentials and the contained attributes, and submit that as a pull request (PR) to the [`irma-demo` scheme](https://github.com/privacybydesign/irma-demo-schememanager). (We can help creating the PR based on the relevant information, if required.) Once that is merged, it becomes automatically available for your IRMA server and for Yivi apps. Then you can start issuing the new credentials in your application during development and in demos, using the [IRMA server](irma-server.md). In this phase, you can finetune your credential structure and your issuance application.
-2. When your credential structure has become finalized and you are ready to move to production, [contact us](/docs/about). Once you are verified as the valid issuer of the credentials and the issuer contract has been signed, your issuer information from the `irma-demo` scheme can be copied over to the production scheme, `pbdf` using another PR. At this point you will need to generate your IRMA issuer private/public keypair (more on that [below](#generating-irma-issuer-keys)), and include the public key in the PR. Once your issuer information is included in the `pbdf` scheme, you can start issuing credentials.
+2. When your credential structure has become finalized and you are ready to move to production, [contact us](/about). Once you are verified as the valid issuer of the credentials and the issuer contract has been signed, your issuer information from the `irma-demo` scheme can be copied over to the production scheme, `pbdf` using another PR. At this point you will need to generate your IRMA issuer private/public keypair (more on that [below](#generating-irma-issuer-keys)), and include the public key in the PR. Once your issuer information is included in the `pbdf` scheme, you can start issuing credentials.
 
 > Credentials within the `irma-demo` scheme are not meant for production application and actual personal data, since attributes within this scheme cannot be trusted: all private keys of all issuers under the `irma-demo` scheme are included in it, so that anyone can issue any `irma-demo` credential containing any attribute values.
 

docs/keyshare-protocol.md

@@ -62,7 +62,7 @@ For these reasons this protocol is very well suited for our aims of making the k
 
 ## The protocol
 
-We now describe the IRMA keyshare protocol. The version of the keyshare protocol documented here is supported by the keyshare server since `v0.11.0` of `irmago`. The previous version of the protocol, which was largely the same but did not use ECDSA for device binding, is documented [here](/docs/v0.9.0/keyshare-protocol). The [Yivi app](app.md) always uses the latest keyshare protocol version that it knows of, but the keyshare server is backwards compatible: it understands both protocols.
+We now describe the IRMA keyshare protocol. The version of the keyshare protocol documented here is supported by the keyshare server since `v0.11.0` of `irmago`. The previous version of the protocol, which was largely the same but did not use ECDSA for device binding, is documented [here](/v0.9.0/keyshare-protocol). The [Yivi app](yivi-app.md) always uses the latest keyshare protocol version that it knows of, but the keyshare server is backwards compatible: it understands both protocols.
 
 ### Overview
 

docs/randomblind.md

@@ -38,7 +38,7 @@ we will explain how randomblind attributes can be used in digital elections.
 Randomblind issuance is enabled in the scheme by adding the `randomblind` XML
 attribute to an `Attribute` tag within the issue specification of a given
 credential.  For more information about schemes, see [this
-page](https://irma.app/docs/schemes/).  In the example below we enable this for
+page](/schemes).  In the example below we enable this for
 the second attribute in the credential. Any or all atributes in a credential
 type can be randomblind.
 
@@ -116,7 +116,7 @@ Idemix public key of the issuer. The issuance goes as follows:
   how the user's secret key remains secret during issuance. 
   The user computes the commitment $U = S^{v'} R_0^{m_0} R_r^{m_{r}'} \mod n$.
   Note that $m_0$ is always the user's secret key. This commitment is sent to
-  the issuer along with a [zero-knowledge proof](https://irma.app/docs/zkp/)
+  the issuer along with a [zero-knowledge proof](zkp)
   of $v', m_0$ and $m_{r}'$.
 
 - The issuer samples a random prime $e$.
@@ -179,7 +179,7 @@ attributes the following system can be realized:
    votes), the user must be uniquely identified in this stage.
 
 2. (Casting the vote). To vote, a user creates an [attribute-based
-   signature](https://irma.app/docs/overview/#attribute-based-signatures) on a
+   signature](overview/#attribute-based-signatures) on a
    "ballot" string, i.e., the user's choice using the randomblind attribute
    acquired in the previous step.  This signature, the choice and the attribute
    are then registered in a database at party B. The signature ensures

docs/session-requests.md

@@ -80,7 +80,7 @@ request.Disclose = irma.AttributeConDisCon{
 }
 ```
 <!--Yivi app-->
-<img src="/docs/assets/condiscon.png" class="ss" alt="condiscon" />
+<img src="/assets/condiscon.png" class="ss" alt="condiscon" />
 <!--END_DOCUSAURUS_CODE_TABS-->
 
 This asks for a (demo) `BSN` attribute, as well as either `street`, `houseNumber` and `city` from `irma-demo.nijmegen.address`, or `address` and `city` from `irma-demo.idin.idin`. The three levels correspond to a *conjunction* of *disjunctions* of *conjunctions* of requested attributes, allowing verifiers to request multiple attribute sets from the user, offering choices for some or all of these sets.
@@ -234,7 +234,7 @@ request.Disclose = irma.AttributeConDisCon{
 }
 ```
 <!--Yivi app-->
-<img src="/docs/assets/optional-disjunction.png" class="ss" alt="optional-disjunction" />
+<img src="/assets/optional-disjunction.png" class="ss" alt="optional-disjunction" />
 <!--END_DOCUSAURUS_CODE_TABS-->
 
 This can be useful when certain attributes are not required, so that if the user does not have them the session does not need to be aborted.
@@ -266,7 +266,7 @@ request.Labels = map[int]irma.TranslatedString{
 }
 ```
 <!--Yivi app-->
-<img src="/docs/assets/condiscon-label.png" class="ss" alt="condiscon-label" />
+<img src="/assets/condiscon-label.png" class="ss" alt="condiscon-label" />
 <!--END_DOCUSAURUS_CODE_TABS-->
 
 In this way each disjunction can be given a optional label explaining to the user the purpose of the disjunction. It is recommended to only provide a label to explain something to the user that would otherwise not be obvious; for example, to request the user to send a work email address instead of a personal one. Repeating the credential or attribute name or description in labels is an antipattern.

docs/what-is-irma.md

@@ -5,8 +5,8 @@ title: What is IRMA?
 IRMA is a set of free and open source software projects implementing the Idemix attribute-based credential scheme, allowing users to safely and securely authenticate themselves as privacy-preserving as the situation permits. Users receive digitally signed attributes from trusted issuer, storing them in their Yivi app, after which the user can selectively disclose attributes to others. Schematically:
 
 <div class="center">
-  <img src="/docs/assets/issuance.png" style="width: 40%; margin-right: 3em" alt="issuance-flow"/>
-  <img src="/docs/assets/disclosure.png" style="width: 40%;" alt="disclosure-flow" />
+  <img src="/assets/issuance.png" style="width: 40%; margin-right: 3em" alt="issuance-flow"/>
+  <img src="/assets/disclosure.png" style="width: 40%;" alt="disclosure-flow" />
 </div>
 
 Using the issuer's digital signature over the attributes the verifier can verify that the attributes were given to the user in the past, and that they have not been modified since.
@@ -53,8 +53,8 @@ In an IRMA session, the [Yivi mobile app](yivi-app.md) performs one of the follo
 This process is depicted schematically and explained in more detail in the [IRMA session flow](what-is-irma.md#irma-session-flow) chapter. For the user, after scanning the QR in his/her Yivi app a disclosure session generally looks like the following. (Attribute-based signature sessions and issuance sessions are identical in terms of their flow (scan qr, provide permission, success screen); only the graphical interface is different.)
 
 <div class="center" style="margin: 3em 0">
-  <img src="/docs/assets/disclose-permission.png" style="width:30%;margin-right:3em" alt="disclose-permission" />
-  <img src="/docs/assets/disclose-done.png" style="width:30%" alt="disclosure-done" />
+  <img src="/assets/disclose-permission.png" style="width:30%;margin-right:3em" alt="disclose-permission" />
+  <img src="/assets/disclose-done.png" style="width:30%" alt="disclosure-done" />
 </div>
 
 ## IRMA servers

docs/yivi-app.md

@@ -18,15 +18,15 @@ img.screenshot {
 }
 </style>
 
-<img src="/docs/assets/yivimobile/1.png" class="screenshot" alt="Screenshot of the Yivi app, showing the introduction screen" />
-<img src="/docs/assets/yivimobile/2.png" class="screenshot" alt="Screenshot of the Yivi app, showing the home screen" />
-<img src="/docs/assets/yivimobile/3.png" class="screenshot" alt="Screenshot of the Yivi app, showing the screen to collect missing data" />
-<img src="/docs/assets/yivimobile/4.png" class="screenshot" alt="Screenshot of the Yivi app, showing the data disclosure screen" />
+<img src="/assets/yivimobile/1.png" class="screenshot" alt="Screenshot of the Yivi app, showing the introduction screen" />
+<img src="/assets/yivimobile/2.png" class="screenshot" alt="Screenshot of the Yivi app, showing the home screen" />
+<img src="/assets/yivimobile/3.png" class="screenshot" alt="Screenshot of the Yivi app, showing the screen to collect missing data" />
+<img src="/assets/yivimobile/4.png" class="screenshot" alt="Screenshot of the Yivi app, showing the data disclosure screen" />
 
 The Yivi app allows users to receive and store digitally signed attributes from trusted issuers, after which they can be selectively disclosed to others. The app is essentially a GUI for the [`irmaclient`](https://github.com/privacybydesign/irmago/tree/master/irmaclient) Go package, which implements the client relative to the [IRMA server](irma-server.md). It is available in the iOS and Android app stores and may also be compiled from source.
 
-<a href="https://play.google.com/store/apps/details?id=org.irmacard.cardemu" target="_blank"><img src="/docs/assets/google-play-badge.png" alt="Play Store" class="badge" width="150"></a>
-<a href="https://itunes.apple.com/nl/app/irma-authentication/id1294092994" target="_blank"><img src="/docs/assets/app-store-badge.png" alt="Apple Store" class="badge" width="150"></a>
+<a href="https://play.google.com/store/apps/details?id=org.irmacard.cardemu" target="_blank"><img src="/assets/google-play-badge.png" alt="Play Store" class="badge" width="150"></a>
+<a href="https://itunes.apple.com/nl/app/irma-authentication/id1294092994" target="_blank"><img src="/assets/app-store-badge.png" alt="Apple Store" class="badge" width="150"></a>
 
 ## Source code
 
@@ -45,4 +45,4 @@ Developer mode thus enables performing IRMA sessions with locally running IRMA s
 For normal users this feature is made difficult to discover by design, for their protection. On the other hand, developers will notice its existence as soon as they try to do an IRMA session with a locally running IRMA server, by the error message displayed by the app.
 
 > Use developer mode with care: when enabled, the Yivi app will not protect you from accidentally sending your attributes unencrypted over the internet.
-> Furthermore, it enables access to debugging features that may make your Yivi app unstable.
+> Furthermore, it enables access to debugging features that may make your Yivi app unstable.

website/README.md

@@ -10,6 +10,14 @@ This website was created with [Docusaurus](https://docusaurus.io/).
 
 # Get Started in 5 Minutes
 
+### Using Docker
+To build the website and run it inside a Docker container, use the following command:
+```sh
+$ docker-compose up
+```
+Afterwards the website is accessible via http://localhost:3000 in your browser.
+
+### For development
 1. Make sure all the dependencies for the website are installed:
 
 ```sh

website/siteConfig.js

@@ -24,7 +24,7 @@ const siteConfig = {
   title: 'IRMA docs', // Title for your website.
   tagline: 'Technical documentation of the IRMA project',
   url: 'https://irma.app', // Your website URL
-  baseUrl: '/docs/', // Base URL for your project
+  baseUrl: '/', // Base URL for your project
   // For github.io type URLs, you would set the url and baseUrl like:
   //   url: 'https://facebook.github.io',
   //   baseUrl: '/test-site/',
@@ -85,7 +85,7 @@ const siteConfig = {
 
   // Add custom scripts here that would be placed in <script> tags.
   scripts: [
-    '/docs/js/navhighlight.js'
+    '/js/navhighlight.js'
   ],
 
   scrollToTop: true,