Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. First, install all the Frontend Requirements listed above & verify the backend/REST API is publicly accessible.
  2. Download the latest dspace-angular release from the DSpace GitHub repository. You can choose to either download the zip or tar.gz file provided by GitHub, or you can use "git" to checkout the appropriate tag (e.g. dspace-7.0-beta5) or branch.
  3. Install all necessary local dependencies by running the following from within the unzipped "dspace-angular" directory

    Code Block
    # change directory to our repo
    cd dspace-angular
    
    # install the local dependencies
    yarn install


  4. Create a Production Configuration file at [dspace-angular]/src/environment/environment.prod.ts. You may wish to use the environment.template.ts as a starting point. This environment.prod.ts file can be used to override any of the default configurations specified in the environment.common.ts (in that same directory).  At a minimum this file MUST include the "ui" and "rest" sections similar to the following (keep in mind, you only need to include settings that you need to modify): 

    Code Block
    export const environment = {   
      // The "ui" section defines where you want Node.js to run/respond. It may correspond to your public URL, but it also may not (if you are running behind a proxy).
      // In this example, we are setting up our UI to just use localhost, port 4000. 
      // This is a common setup for when you want to use Apache or Nginx to handle HTTPS and proxy requests to Node on port 4000
      ui: { 
          ssl: false,
          host: '0.0.0.0localhost',
          port: 4000, 
          // NOTE: Space is capitalized because 'namespace' is a reserved string in TypeScript
          nameSpace: '/' 
      }
      // This example is valid if your Backend is publicly available at https://api.mydspace.edu/server/
      // The REST settings MUST correspond to the public URL of the backend. Usually, this means they must be kept in sync
      // with the value of "dspace.server.url" in the backend's local.cfg
      rest: { 
          ssl: true, 
          host: 'api.mydspace.edu',
          port: 443, 
          // NOTE: Space is capitalized because 'namespace' is a reserved string in TypeScript
          nameSpace: '/server' 
      }
    };


    1. HINT #1: In the "ui" section above, you may wish to start with "ssl: false" and "port: 4000" just to be certain that everything else is working properly.  With those settings, you can quickly test your UI by running "yarn start" and trying to access it via http://[mydspace.edu]:4000/ from your web browser.  KEEP IN MIND, we highly recommend always using HTTPS for Production.
    2. HINT #2: If Node throws an error saying "listen EADDRNOTAVAIL: address not available", try setting the "host" to "0.0.0.0.  While this isn't your Public URL, it should allow Node to respond on your specified "port" when the " or "localhost".  Usually that error is a sign that the "host" is not recognized.
    3. If there are other settings you know you need to modify in the default environment.common.ts configuration file you can also copy them into this same file.
  5. Build the User Interface for Production. This uses your environment.prod.ts and the source code to create a compiled version of the UI in the [dspace-angular]/dist folder

    Code Block
    yarn run build:prod


    1. HINT: if you change/update your environment.prod.ts, then you will need to rebuild the UI application (i.e. rerun this command).
  6. Assuming you are using PM2, create a JSON configuration file describing how to run our UI application.  This need NOT be in the same directory as the dspace-angular codebase itself (in fact you may want to put the parent directory or another location). Keep in mind the "cwd" setting (on line 5) must be the full path to your [dspace-angular] folder.

    Code Block
    titledspace-angular.json
    {
        "apps": [
            {
                "name": "dspace-angular",
                "cwd": "/home/dspace/dspace-angular",
                "script": "yarn",
                "args": "run serve:ssr",
               "interpreter": "none"
            }
        ]
    }


  7. Now, start the application using PM2 using the configuration file you created in the previous step

    Code Block
    # In this example, we are assuming the config is named "dspace-angular.json"
    pm2 start dspace-angular.json
    
    # To see the logs, you'd run
    # pm2 logs
    
    # To stop it, you'd run
    # pm2 stop dspace-angular.json


    1. For more PM2 commands see https://pm2.keymetrics.io/docs/usage/quick-start/
    2. HINT: You may also want to install/configure pm2-logrotate to ensure that PM2's log folder doesn't fill up over time.
  8. At this point, the User Interface should be available at the URL you configured in your environment.prod.ts
    1. For an example of what the default frontend looks like, visit the Demo Frontend: https://demo7.dspace.org/ 
  9. For HTTPS (port 443) support, you have two options
    1. (Recommended) You can install either Apache HTTPD or Nginx , configuring SSL at that level, and proxy requests to PM2 (on port 4000).  This is our current recommended approach. Plus, as a bonus, if you want to host the UI and Backend on the same server, you can use just one Apache HTTPD (or Nginx) to proxy to both. These instructions are specific to Apache.
      1. Install Apache HTTPD, e.g. sudo apt install apache2
      2. Install the mod_proxy and mod_proxy_http modules, e.g. sudo en2mod proxy; sudo a2enmod proxy_http
      3. Restart Apache to enable
      4. Now, setup a new VirtualHost for your site (preferably using HTTPS / port 443) which proxies all requests to PM2 running on port 4000.

        Code Block
        <VirtualHost _default_:443>
            .. setup your host how you want, including log settings...
        
            SSLEngine on
            SSLCertificateFile [full-path-to-PEM-cert]
            SSLCertificateKeyFile [full-path-to-cert-KEY]
        
            # Proxy all HTTPS requests from Apache to PM2 on port 4000
            ProxyPass / http://127.0.0.1:4000/
            ProxyPassReverse / http://127.0.0.1:4000/
        </VirtualHost>


    2. (Alternatively) You can use the basic HTTPS support built into dspace-angular node server.  (This may currently be better for non-Production environments as it has not been well tested) 
      1. Create a [dspace-angular]/config/ssl/ folder and add a key.pem and cert.pem to that folder (they must have those exact names)
      2. Enable "ui.ssl" (set to true)
      3. Update your "ui.port" to be 443
        1. In order to run Node/PM2 on port 443, you also will likely need to provide node with special permissions, like in this example.
      4. Rebuild and then restart the app in PM2
      5. Keep in mind, while this setup is simple, you may not have the same level of detailed, Production logs as you would with Apache HTTPD or Nginx
  10. Additional UI configurations are described in the environment.common.ts and at https://github.com/DSpace/dspace-angular/blob/main/docs/Configuration.md  (More documentation will be coming soon)

...

First, double check that you are seeing that exact error message.  403 Forbidden can error may be thrown in a variety of scenarios. ..it could be page that For example, a 403 may be thrown if a page requires a login, if you could have entered an invalid username or password, or you could even be seeing even sometimes when there is a CORS error (see previous installation issue for how to solve that). 

If you are seeing the message "Invalid CSRF Token" message (especially on every login), this is usually the result of a configuration / installation setup issue.

Here's some things you should double check:

  • If you need to be able to login to the REST API from other domains, then your Backend must be running HTTPS.  
    • If the REST API Backend is running HTTP, then it will always send the required DSPACE-XSRF-COOKIE cookie with a value of SameSite=Lax.  This setting means that the cookie will not be sent (by your browser) to any other domains. Effectively, this will block all logins from any domain that is not the same as the REST API (as this cookie will not be sent back to the REST API as required for CSRF validation).  In other words, running the REST API on HTTP is only possible if the User Interface is running on the exact same domain. For example, running both on 'localhost' with HTTP is a common development setup, and this will work fine.
    • In order to allow for cross-domain logins, you MUST enable HTTPS on the REST API. This will result in the DSPACE-XSRF-COOKIE cookie being set to SameSite=None; Secure.  This setting means the cookie will be sent cross domain, but only for HTTPS requests. It also allows the user interface (or other client applications) to be on any domain, provided that the domain is trusted by CORS (see rest.cors.allowed-origins setting in REST API)
  • Verify that your User Interface's "rest" section matches the value of "dspace.server.url" configuration on the Backend.  This simply ensures your UI is sending requests to the correct REST API.  Also pay close attention that both specify HTTPS when necessary (see previous bullet).
  • Verify that your "dspace.server.url" configuration on the Backend matches the public URL of the REST API (i.e. the URL you see in the browser).  This must be an exact match: mode (http vs https), domain, port, and subpath(s) all must match.
  • Verify that your "dspace.ui.url" configuration on the Backend matches the public URL of your User Interface (i.e. the URL you see in the browser). This must be an exact match: mode (http vs https), domain, port, and subpath(s) all must match.
  • If you are running a custom application, or accessing the REST API from the command-line (or other third party tool like Postman), you MUST ensure you are sending the CSRF token on every modifying request.  See our REST Contract for more details https://github.com/DSpace/RestContract/blob/main/csrf-tokens.md

...