fix url error
This commit is contained in:
@@ -2,7 +2,7 @@
|
||||
title: CSCI 1100 - Test 4 Overview and Practice Questions
|
||||
subtitle:
|
||||
date: 2024-04-26T03:54:07-04:00
|
||||
slug: csci-1100-exam-4overview
|
||||
slug: csci-1100-exam-4-overview
|
||||
draft: true
|
||||
author:
|
||||
name: James
|
||||
|
||||
@@ -47,26 +47,26 @@ repost:
|
||||
|
||||
<!--more-->
|
||||
|
||||
## Before Start
|
||||
## Introduction
|
||||
|
||||
LobeChat defaults to using IndexedDB to store user data, which means the data is stored locally in the browser. This results in the inability to synchronize data across multiple devices and the risk of data loss. At the same time, LobeChat has a server-side database version that addresses the aforementioned issues and also enables the use of a knowledge base feature.
|
||||
By default, LobeChat uses IndexedDB to store user data, meaning the data is stored locally in the browser. Consequently, it becomes impossible to synchronize across multiple devices and poses a risk of data loss. Meanwhile, there is a server database version of LobeChat that addresses these issues and also allows for knowledge base functionality.
|
||||
|
||||
However, configuring the LobeChat DB version is not straightforward. It involves several parts: configuring the database, setting up the authentication service, and configuring the S3 storage service [^1].
|
||||
However, configuring the LobeChat DB version isn't straightforward. It involves several parts: setting up the database, configuring authentication services, and configuring S3 storage[^1].
|
||||
|
||||
[^1]: Refer to the official documentation https://lobehub.com/en/docs/self-hosting/server-database
|
||||
[^1]: See official documentation https://lobehub.com/en/docs/self-hosting/server-database
|
||||
|
||||
## Configuring Logto
|
||||
|
||||
I recommend deploying the Logto service separately, as it may also be used in other projects and can be managed independently.
|
||||
I recommend deploying the Logto service separately to potentially use it in other projects and manage them independently.
|
||||
|
||||
First, create a new directory and navigate into it:
|
||||
First, create a directory and enter it:
|
||||
|
||||
```bash
|
||||
mkdir logto
|
||||
cd logto
|
||||
```
|
||||
|
||||
Here is my `docker-compose.yaml` file, which you can refer to and modify the relevant parts to suit your own needs:
|
||||
Here is my `docker-compose.yaml` file for reference. Modify the relevant parts according to your own setup.
|
||||
|
||||
```yaml
|
||||
services:
|
||||
@@ -105,13 +105,13 @@ services:
|
||||
entrypoint: ['sh', '-c', 'npm run cli db seed -- --swe && npm start']
|
||||
```
|
||||
|
||||
After making the modifications, write them into the `docker-compose.yaml` file. Then, run the container:
|
||||
After modifying, write the `docker-compose.yaml` file. Then start the container:
|
||||
|
||||
```bash
|
||||
docker compose up -d
|
||||
```
|
||||
|
||||
Remember to configure the reverse proxy correctly. This proxy must support HTTPS because Logto's various APIs must run in a secure environment, otherwise, errors will occur [^2]. Moreover, simply having HTTPS is not enough; you must also set the value of the `X-Forwarded-Proto` header to `https` to inform Logto that the user is accessing via HTTPS. I use Nginx as the reverse proxy service, and the following configuration can be referenced. Remember to modify the content according to your situation (e.g., `proxy_pass`).
|
||||
Remember to correctly configure a reverse proxy; this proxy must support HTTPS because all of Logto's APIs must be run in a secure environment, otherwise errors will occur[^2]. Additionally, just having HTTPS isn't enough; you also need to set the `X-Forwarded-Proto` header value to `https` to inform Logto that users are accessing it via HTTPS. I use Nginx as my reverse proxy service and provide a reference configuration below (modify according to your situation).
|
||||
|
||||
[^2]: Discussion on errors https://github.com/logto-io/logto/issues/4279
|
||||
|
||||
@@ -127,30 +127,30 @@ location / {
|
||||
}
|
||||
```
|
||||
|
||||
Additionally, this is just a small part of the configuration. If you are manually crafting the Nginx configuration file rather than managing it through a graphical tool like Nginx Proxy Manager, you will need to complete the other parts yourself. Do not simply copy and paste. In other words, if you are using Nginx Proxy Manager, you can directly copy the modified `proxy_pass` into the corresponding reverse proxy's Advanced configuration box.
|
||||
If you are manually configuring your Nginx configuration file rather than using a graphical tool like Nginx Proxy Manager, you need to complete other parts on your own (do not directly copy). In other words, if you use Nginx Proxy Manager, you can modify the `proxy_pass` and then directly input it into the Advanced settings of the corresponding reverse proxy.
|
||||
|
||||
Afterward, you can visit the ADMIN_ENDPOINT to complete registration and configuration (the first registered account will automatically become an administrator). Remember to add an Application (in preparation for the installation of the LobeChat DB version), and the type can be selected as Next.js (App Router). There are several key parameters that should not be written incorrectly (replace the domain name with your own LobeChat DB version instance):
|
||||
Afterwards, you can access the ADMIN_ENDPOINT to complete registration and configuration (the first registered account will automatically become an admin), remember to add an Application (prepare for LobeChat DB version installation), with a type selected as Next.js (App Router). Several key parameters should not be written incorrectly (replace domain names with your own LobeChat DB instance):
|
||||
|
||||
- `Redirect URIs` write `https://lobe.example.com/api/auth/callback/logto`
|
||||
- `Post sign-out redirect URIs` write `https://lobe.example.com/`
|
||||
- `CORS allowed origins` write `https://lobe.example.com`
|
||||
|
||||
There are three parameters that we will use later in the configuration of the LobeChat DB version: Issuer endpoint, App ID, and App secrets (this needs to be added). You can take note of them.
|
||||
There are three parameters that we will use when configuring the LobeChat DB version: Issuer endpoint, App ID, and App secrets (add one). Note them down.
|
||||
|
||||
You can also visit the user ENDPOINT's `/demo-app` path to test login, registration, and other functions to see if they are working properly. If everything is OK, then Logto is fine, and you can proceed with the following tasks.
|
||||
You can also visit the `/demo-app` path of your user ENDPOINT to test login and registration functions. If everything is fine, then Logto should be properly configured, allowing you to proceed with further steps.
|
||||
|
||||
## Configuring MinIO
|
||||
|
||||
I also recommend deploying MinIO separately, as it can be used for other projects.
|
||||
I recommend deploying MinIO separately for potential use in other projects as well.
|
||||
|
||||
Create a directory and navigate into it:
|
||||
Create a directory and enter it:
|
||||
|
||||
```bash
|
||||
mkdir minio
|
||||
cd minio
|
||||
```
|
||||
|
||||
Here is my `docker-compose.yaml` file, which you can refer to:
|
||||
Here is my `docker-compose.yaml` file for reference:
|
||||
|
||||
```yaml
|
||||
services:
|
||||
@@ -178,15 +178,13 @@ minio:
|
||||
command: server /data --console-address ":9090"
|
||||
```
|
||||
|
||||
After making the modifications, write them into the `docker-compose.yaml` file. Then, run the container:
|
||||
After modifying, write the `docker-compose.yaml` file. Then start the container:
|
||||
|
||||
```bash
|
||||
docker compose up -d
|
||||
```
|
||||
|
||||
Next, log in to your MinIO instance from your MINIO_BROWSER_REDIRECT_URL, create a Bucket, and name it `lobe` as an example. If you change it to something else, remember to modify the corresponding configuration files.
|
||||
|
||||
In the Access Policy, choose Custom and fill in a configuration similar to the following (using `lobe` as the Bucket name):
|
||||
Subsequently, log into your MinIO instance from your MINIO_BROWSER_REDIRECT_URL, create a Bucket (e.g., name it as `lobe`; if you change this, remember to modify corresponding configuration files), and configure an Access Policy similar to the following JSON file:
|
||||
|
||||
```json
|
||||
{
|
||||
@@ -247,18 +245,18 @@ In the Access Policy, choose Custom and fill in a configuration similar to the f
|
||||
}
|
||||
```
|
||||
|
||||
Then, go to Access Keys and create a token. Please save the values here, as they will be used in the subsequent configuration of the LobeChat DB version.
|
||||
Then go to Access Keys and create a token, save these values as they will be used in the LobeChat DB version configuration.
|
||||
|
||||
## Configuring the LobeChat DB Version
|
||||
## Configuring LobeChat DB Version
|
||||
|
||||
Next, we will start configuring the LobeChat DB version. First, create a directory and navigate into it:
|
||||
Now we start configuring the LobeChat DB version. First, create a directory and enter it:
|
||||
|
||||
```bash
|
||||
mkdir lobe-db
|
||||
cd lobe-db
|
||||
```
|
||||
|
||||
Here is the `docker-compose.yaml` configuration file I use. Remember to modify it to your values:
|
||||
Here is my `docker-compose.yaml` file for reference; remember to modify according to your setup:
|
||||
|
||||
```yaml
|
||||
services:
|
||||
@@ -311,56 +309,55 @@ services:
|
||||
restart: always
|
||||
```
|
||||
|
||||
For security reasons, `KEY_VAULTS_SECRET` and `NEXT_AUTH_SECRET` need to be a random 32-character string, which can be generated by running the command `openssl rand -base64 32`.
|
||||
For security reasons, `KEY_VAULTS_SECRET` and `NEXT_AUTH_SECRET` should be a random 32-character string. You can generate it using the command `openssl rand -base64 32`.
|
||||
|
||||
Then, change the domain names in the environment variables to your own. In addition, there are several Logto values, which are related as follows:
|
||||
Then modify domain names in environment variables to your own setup. Additionally, several Logto values need to be set:
|
||||
|
||||
- `Issuer endpoint` corresponds to `LOGTO_ISSUER`
|
||||
- `App ID` corresponds to `LOGTO_CLIENT_ID`
|
||||
- `App secrets` corresponds to `LOGTO_CLIENT_SECRET`
|
||||
|
||||
These can all be found on the created Application page.
|
||||
These can all be found on the Application page you created.
|
||||
|
||||
Regarding the S3 configuration, remember to modify it, such as `S3_ENDPOINT`, `S3_BUCKET`, `S3_PUBLIC_DOMAIN`, `S3_ACCESS_KEY_ID`, `S3_SECRET_ACCESS_KEY`. As for `S3_ENABLE_PATH_STYLE`, it is generally `1`. If your S3 provider uses virtual-host, change it to `0`.
|
||||
For S3 configuration, also modify accordingly (e.g., `S3_ENDPOINT`, `S3_BUCKET`, `S3_PUBLIC_DOMAIN`, `S3_ACCESS_KEY_ID`, `S3_SECRET_ACCESS_KEY`). As for `S3_ENABLE_PATH_STYLE`, it is usually set to `1`. If your S3 provider uses virtual-host style, change this value to `0`.
|
||||
|
||||
{{< admonition type=question title="What is the difference between path-style and virtual-host?" open=true >}}
|
||||
path-style and virtual-host are different ways to access buckets and objects in S3, with different URL structures and domain name resolutions.
|
||||
{{< admonition type=question title="What are the differences between path-style and virtual-host?" open=true >}}
|
||||
Path-style and virtual-host are different ways of accessing buckets and objects in S3. The URL structure and domain name resolution differ:
|
||||
|
||||
Assuming the S3 provider's domain is s3.example.net, the bucket is mybucket, and the object is config.env, the specific differences are as follows:
|
||||
|
||||
- path-style: s3.example.net/mybucket/config.env
|
||||
- virtual-host: mybucket.s3.example.net/config.env
|
||||
Assuming your S3 provider's domain is s3.example.net, bucket is mybucket, object is config.env, the specific differences are as follows:
|
||||
- Path-style: `s3.example.net/mybucket/config.env`
|
||||
- Virtual-host: `mybucket.s3.example.net/config.env`
|
||||
{{< /admonition >}}
|
||||
|
||||
Finally, configure your API-related content (optional), which is exemplified in my configuration for using OpenAI. If you do not configure it on the server side, users will need to fill it in themselves on the frontend.
|
||||
Finally, configure your API-related content (optional). My configuration example uses OpenAI. If you do not set it up on the server side, users will need to enter their own keys in the frontend.
|
||||
|
||||
After making the modifications, write them into the `docker-compose.yaml` file. Then, run the container:
|
||||
After modifying, write the `docker-compose.yaml` file and start the container:
|
||||
|
||||
```bash
|
||||
docker compose up -d
|
||||
```
|
||||
|
||||
In theory, you should now be able to access and use the LobeChat DB version. If you need to deploy it in a production environment, please carefully check to ensure there are no security issues. If you have any questions, feel free to comment.
|
||||
In theory, you can now access LobeChat DB version. Before deploying to production, carefully check for any security issues. If you have questions, feel free to comment.
|
||||
|
||||
## Extended Content
|
||||
## Additional Content
|
||||
|
||||
### Customizing Logto Login/Registration Options
|
||||
|
||||
In the Logto management page, you can see a Sign-in experience, where there are various customization options, such as enabling registration, disabling registration, and using social media SSO. The default Sign-up identifier is Username. I recommend changing it to Email address after configuring SMTP in Connectors, otherwise, users will not be able to retrieve their passwords via email, and forgetting the password will be problematic.
|
||||
On the Logto management page, there is a Sign-in experience section with various customization options such as enabling or disabling registration and using social media SSO. By default, the Sign-up identifier is Username; I recommend configuring SMTP in Connectors to change it to Email address so users can recover their passwords via email.
|
||||
|
||||
### Enabling Dark Mode for Logto Login/Registration Pages
|
||||
|
||||
In the Logto management page, you can see a Sign-in experience, where checking Enable dark mode will enable dark mode.
|
||||
On the Logto management page, under Sign-in experience, check Enable dark mode to turn on dark mode.
|
||||
|
||||
### Enabling GitHub Login/Registration Options for Logto
|
||||
### Adding GitHub Login/Registration Options in Logto
|
||||
|
||||
In the Logto management page, you can see a Connectors, where you can add GitHub in the Social connectors, and the same applies to others.
|
||||
In the Logto management page, go to Connectors and add GitHub under Social connectors. Other options are similar.
|
||||
|
||||
### Configuring More Models
|
||||
### Configuring Additional Models
|
||||
|
||||
LobeChat supports many models, and you can set different environment variables to start them. You can refer to the official documentation [LobeChat Model Service Providers - Environment Variables and Configuration](https://lobehub.com/en/docs/self-hosting/environment-variables/model-provider) for the configuration options and explanations of `OPENAI_MODEL_LIST`. Of course, there are also options for other model providers, such as DeepSeek.
|
||||
LobeChat supports many models; you can set different environment variables to enable them. See the official documentation for `OPENAI_MODEL_LIST` configuration options and explanations [here](https://lobehub.com/en/docs/self-hosting/environment-variables/model-provider). There are also other model provider options like DeepSeek.
|
||||
|
||||
Of course, you can also obtain the Model List through the API on the frontend and then select the required models.
|
||||
You can retrieve Model List via API on the frontend to select needed models.
|
||||
|
||||
## References
|
||||
|
||||
|
||||
Reference in New Issue
Block a user