Activities of "gterdem"

Can you verify that identityserver (localhost:44360) is up and running?

2021-12-07 23:08:05.788 +05:30 [INF] Now listening on: https://localhost:44343

Logs you have shared is from development, not the production you are having problem with.

Before building your application on production environment, run the command abp install-libs under Web and IdentityServer projects. That will install and map related nodemodule files under libs folder.

Also verify this by checking file physical location under Release/publish/wwwroot. You can also manually add this files to your server if you are making file system publish.

You need to pass --url argument to kestrel.. 5000/5001 are default ports.

You should run as dotnet run --url http://0.0.0.0:44367

Or use environment variables.

Hello, The log file you have shared is 610 mb. If it is the application source code, please remove it's link since this is public platform. Can you paste the log changes of identityserver project after you logout-login when the error occurs?

Hi LawrenceKwan,

You can use Client Credentials Flow (server to server) to request an access token.

Client Credentials Flow Summary:

1. You create a client (https://docs.identityserver.io/en/latest/quickstarts/1_client_credentials.html#creating-the-client)
2. You make an http request to Discovery Endpoint (Using IdentityModel nuget package)
3. You make access token request
4. You add the token as bearer to header and make request to the resource with the defined scopes

Using Client Credentials Flow in ABP

1. You can create a client (either IdentityServerDataSeeder or IdentityServer UI) Now, if your application is and ABP application (has a module class and extending AbpModule class), you can add Volo.Abp.Http.Client.IdentityModel nuget package that automates steps 2, 3 and 4. You can check this part of the documentation for more information. However, since you mentioned it is an external software that can be written in any language; generic client credentials flow rules apply as I have mentioned above. There is one caveat, If your application service is protected with a permission as below: You need to add related permission to the client you have created at step 1 using either IdentityServerDataSeeder or IdentityServer UI. Here is a related part of documentation that can help.

We're using Serilog.Sinks.Async in templates.

Update:

Log.Logger = new LoggerConfiguration()
                .WriteTo.Async(c => c.File("Logs/logs.txt"))

to

Log.Logger = new LoggerConfiguration()
                .WriteTo.Async(c => c.File("Logs/logs.txt", rollingInterval:RollingInterval.Day))

Or you can directly use Serilog File Sink

You don't need to use abp login command in pipeline, just copy NuGet.Config that contains ABP_COMMERCIAL_NUGET_SOURCE.

About using DbMigrator in pipeline; I do not know your deployment environment but If you are using kubernes, you can use Job.

For DbMigrator helm template, you can use something similar to:

apiVersion: batch/v1
kind: Job
metadata:
  name: {{ .Release.Name }}-{{ .Chart.Name }}
spec:
  activeDeadlineSeconds: 180
  template:
    spec:
      containers:
      - image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
        imagePullPolicy: {{ .Values.image.pullPolicy }}
        name: {{ .Release.Name }}-{{ .Chart.Name }}
        env:
        - name: "ConnectionStrings__Default"
          value: {{ .Values.config.connectionStrings.default }}
        - name: "DOTNET_ENVIRONMENT"
          value: "{{ .Values.config.dotnetEnv }}"
          {{- if .Values.env }}
{{ toYaml .Values.env | indent 8 }}
          {{- end }}

      restartPolicy: Never
  backoffLimit: 10

Eventually, DbMigrator should be run as a console application.

Thank you, please let us know if you still have problems

Closing the issue since your problem seems resolved. Feel free to reopen if you think your problem persists.