Client Server

The client server is used to process the requests from the frontend and send back an answer.

In the current setup the client server serves the webpage as static content. All other requests are api calls.

Important Issues

Important hints

Because of firefox we use an interceptor to set the content type for all api paths to json (see Startup.cs > Configure) so if we want to send another Type we need to set Respone.ContentType to another type.

Installation

TODO

To install the client server you can use the install.sh script in the install directory.

Install requirements

You need to have the following programs installed and configured

• PostgresSQL - https://www.postgresql.org/download/
  • check:
• .Net Core - https://www.microsoft.com/net/core
  • check: dotnet --version

Install

to install all dependencies run in the root directory [Client-Server]/src/ClientServer/

dotnet restore

After this is done you can install the database via

dotnet ef database update

This will create the database (if it's not yet exist) and apply the scheme to it (creating all tables...).

Now you need to setup the first user and some basic data (test types...).

To do so start the server and navigate to http://myServerOrLocalhost:Port/api/init this will check if at least one user exists. If >= 1 user exists this won't change anything. If you have 0 users (a fresh install) then all basic data will be created.

The first user has all permissions (like an admin) with

id: j
pw: j

this should be changed after the first login!!

Running the Server (better)

See also https://docs.microsoft.com/de-de/dotnet/articles/core/tools/dotnet-publish See also https://docs.microsoft.com/de-de/dotnet/articles/core/rid-catalog

First you need to build the server. Open a shell and cd to the directory /ClientServer/src/ClientServer/ then run

dotnet publish --runtime debian.8-x64 --configuration Release --framework netcoreapp1.0 -o output/ClientServer

to build the project (for debian). The output is not at ClientServer/src/ClientServer/output/ClientServer.

Copy the folder at ClientServer/src/ClientServer/output/ClientServer/ to your target server

To run the server execute

dotnet ClientServer.dll

It might be useful to setup systemctl to start the Syndrom Server at startup. See also https://docs.microsoft.com/en-us/aspnet/core/publishing/linuxproduction

For Better Performance you might use nginx (as a reverse proxy) to serve static files and redirect requests.

In the dir /server/ are some scripts that might be useful...

Running the server

The easies way to run the server open a shell in the directory [client-server]/src/ClientServer/ and run dotnet run ClientServer.xproj.
Now the server is running and you can open the browser at http://localhost:8000/index_deploy.html

When you use a webpack-dev server (for development) from the frontend-project you can use http://localhost:8000/index.html

To change the port you currenlty needs to set the variable Port in the Startup.cs file in [client-server]/src/ClientServer/

See https://github.com/aspnet/KestrelHttpServer/issues/639 for more information

Addin a new programming language

To add a new programming language (plang) you need to add the appropriate line in the database plang-table (normally PLangs)

the plangs table has the following minimal structure

• id the id of the row
• displayName the name that is used to display the plang
• internalName the internal name that is used to handle the plang e.g. sending a test request to the test server or the apply syntax highlighting in the frontend

So the internalName name must match the programming language internalName in the test server.
It's also important to note here that adding the plang in the client-server won't add the plang to the test-server automatically (because they are separate systems).
To add the plang to the test server too, read the test-server documentation.

Directory/File Structure

• output - generated when publishing the app, contains the published app
• bin - [auto generated from visual studio] contains the temporarily outputs of the compilation (can be used for development)
• Controllers - contains all controller files to handle the requests
• Db - contains the db context file (the configuration for the database and the model) and a readme file for common interactions with the database and entity framework
• Helpers - contains some helper classes used for different purposes
• Migrations - [auto generated from entity framework] contains the migrations for the database
• Models - contains the files that describes the model (see the model.md file in the docs)
• obj - [auto generated from visual studio] normally used for production output in normal apps, but this is an asp app, can be ignored?
• Properties - [auto generated from visual studio] do not delete
• Schedulers - all schedulers for the project e.g. periodically check to release or derelease releases
• wwwroot - the files that will/should be served from the web server (so anything in this directory will be accessible to everyone)
• appsettings.json - the appsettings.json.md file in the docs (/docs/)
• Program.cs - the main entry point for the app
• project.json - the configuration file for the nuget resources (hopefully deleted in future)
• project.lock.json - lockfile for project.json
• Startup.cs - the asp.net startup file that configures services and the app
• web.config - the web config file??

wwwroot files

Because the frontend is really just a single page application is basically enough to serve just 1 main file (and some .css files...)

• wwwroot/index.html is the index file or development (when using webpack-dev-server see frontend docs)

• wwwroot/index_deploy.html is the index file for production (it uses the bundled version of the )

• wwwroot/news.html the news site content (that will be inserted in the news page) (currently it's the default site)

• wwwroot/firstLoginExternalLogin.html and wwwroot/firstLoginExternalLogin.js is the landing page when the user logs in with ostepu for the first time... in this case the user need to specify a password for syndrom (the user data is automatically received from ostepu)

  • wwwroot/static/sha512.js is needed to hash the passwords
  • wwwroot/static/semantic.min.css is needed to style the site

• wwwroot/passwordMigrationHelper.html and wwwroot/passwordMigrationHelper.js a site where a user can input a text that will be hashed with the frontend hash algorithem and then sent to the backend and hashed a second time (like a normal login)

  • wwwroot/static/sha512.js is needed to hash the passwords
  • wwwroot/static/semantic.min.css is needed to style the site

• wwwroot/static/bundle.js beinhaltet die gebundelte version der frontend app

  • wwwroot/static/styles.css contains the styles for the frontend app
  • wwwroot/static/dark.css contains the dark theme for the frontend app

• wwwroot/9ed4669f524bec38319be63a2ee4ba26.gif is (probably?) used by magnific popup

• wwwroot/themes/ everything in this directory belongs somehow to semantic ui and is needed (some fonts...) (to work offline??)

External Login (Ostepu)

In the config files are several options for the external login...

So the normal workflow is

• client is redirected to the special path /api/auth/login/external (GET) (in the AuthController)
  a tid needs to be added to the url from the external login e.g. /api/auth/login/external?tid=xxxxxx
• the server tries to get data from the external login source via the appsettings.json property ExternalLoginUrl, so a get request is send to the external login to the path ExternalLoginUrl + tid e.g. when ExternalLoginUrl = /external_ip/login/ and the tid = xxx then the path would be /external_ip/login/xxx
• if the reuqest was successful then the json body response is deserialized to a OstepuLoginContent object
  • else a negative response is returned
  • if the user has no login for syndrom yet (no external user) then a external user is created at syndrom, the user has no password yet
    • the user is then redirected to the appsettings.json LoginExternalFirstTimeSite page but the tid is appended a query parameter e.g. when LoginExternalFirstTimeSite = /firstLoginExternalLogin.html then redirect to /firstLoginExternalLogin.html?tid=xxx
      here the user needs to specify a password for the new syndrom user (the external register page)
  • if the user has already a login then he/she is redirected to appsettings.json MainEntrySite
  • if the user has already a login but the password is still empty (never set) then he/she is redirected to firstLoginExternalLogin.html?tid=xxx (see above)

the url /api/auth/register/external (POST) with a tuple

{
  tid: string
  pw: string
}

first tries to get the user data from appsettings.json ExternalLoginUrl + tuple.tid e.g. /external_ip/login/xxx
the password is then assigned (and hashed) to the external user (external user in syndrom)
if a user tries to login via external but the password is not yet set then he/she is redirected to the set password external page (appsettings.json LoginExternalFirstTimeSite + ?tid=[tid])

the register function checks for empty passwords and the external login register page also checks for empty passwords...
the login function blocks empty password!!

Hints

• when the server is shutdown and some assessment was running will it ever finish?
  • it should because we now chec/run on server startup a new assessment check for assessments that haven't finished and rerun them
• HttpDelete cannot take [FromBody] arguments because vue-resource does not support body data when sending delete request --> use url argument e.g. HttpPost("{id}")