Skip to content

send with CLI at only one client/user + CLI and letsencrypt-certificate #29

Description

@reschresch

Hello,
in my test-environment I have 2 clients (smartphones) who logged in with different usernames.
Now I want to send a message over the CLI only to "user1", but I dont know what's the syntax.

And: I have a letsencrypt-certificate. With the smartphone-client I can check on that the client ignore somewhat so he had login correctly. Is this possible with the CLI too?

With best regards,
reschresch

Activity

  1. jmattheis commented on Oct 8, 2019

    @jmattheis
    Member

    in my test-environment I have 2 clients (smartphones) who logged in with different usernames.

    Do you mean different users or only different clients of one user?

    Now I want to send a message over the CLI only to "user1", but I dont know what's the syntax.

    Have you followed the steps on https://github.com/gotify/cli#installation ? There are examples for sending a message.

    And: I have a letsencrypt-certificate. With the smartphone-client I can check on that the client ignore somewhat so he had login correctly. Is this possible with the CLI too?

    If you have a letsencrypt certificate all should work out of the box, as the certs are generally accepted by your OS without further configuration.

  2. reschresch commented on Oct 8, 2019

    @reschresch
    Author

    Hello jmattheis,

    • I have two clients (two smartphones) with two different usernames.
    • I follow the steps with the cli-examples.
      I send in the CLI a "gotify push "Test001".

    After many tries (where nothing appears on the phones, but I see in the server-console that something happened) on one phone with "user1" the message appears, on the 2nd (user2) not.
    OK, I dont know why is appears at this time, but something goes right. I'm happy.
    After that I try again, on both phones the same user - on both phones the message appears.
    OK, I think I understand a little bit - I'm happy again.
    After that I init the cli again and use an app-token I generate with the browser-web-ui.
    No message appears. (I see in the server console that it generate a new line when I send the message)

    Hmmmm, what can I do?
    I would be thankful if you can explain me how I can send with the cli a message to user:"user1" on client:"phone1".
    I try to understand the context between user and client as "receiving devices" and the app as sender.

    It's possible I read not enough the docu.
    Give me a hint (link) where I can find a docu to that topic.

    My first thought was that in the cli is a parameter like "gotify push -receive "user1" "messagetext". (Or somtehing like that.)
    But I think I have not understand your principle at this time.

    With best regards,

    reschresch

  3. jmattheis commented on Oct 9, 2019

    @jmattheis
    Member

    Have a look at https://gotify.net/docs/ for explanation what a client/application/user is.

    When you init the cli, you either provide login credentials or an application token. When you now use cli push you send a message to the user that owns the application. So it is not possible to send a message to user2 with an application token from user1.

    Are there any errors in the log or rather could you paste the whole output of cli init and the gotify/server log? (you can hide urls)

  4. reschresch commented on Oct 9, 2019

    @reschresch
    Author

    Hello jmattheis,
    thank you for this information.
    Actual I have no errors in my log - I understand now that there is a relationship between the used app-token (sender) and the client (receiver).
    I will try it out.
    Yesterday I implement my (existing) letsencrypt-certificate. I put it my config-file and my browser runs perfectly without error.
    But the CLI throws an error:
    http: TLS handshake error from xxx.yyy.zzz.aaa:44140: remote error: tls: bad certificate

    This is my server-config for this part:
    ssl:
    enabled: true # true # if https should be enabled
    redirecttohttps: true # redirect to https if site is accessed by http
    listenaddr: "xxx.yyy.zzz.aaa" # the address to bind on, leave empty to bind on
    port: 111 # the https port
    certfile: /etc/letsencrypt/live/XXXDomain.YY/cert.pem # the cert file
    certkey: /etc/letsencrypt/live/XXXDomain.YY/privkey.pem # the cert key
    enabled: false # if the certificate should be requested from letsencrypt
    accepttos: true # if you accept the tos from letsencrypt
    cache: data/certs # the directory of the cache from letsencrypt
    hosts: # the hosts for which letsencrypt should request certificates
    - XXXDomain.YY

    I will be very happy if you can give me a hint.

    With best regards,
    reschresch

  5. jmattheis commented on Oct 9, 2019

    @jmattheis
    Member

    Could you run the following command?

    $ curl -vvv https://yourdomain.de/version
    

    and paste the output

  6. reschresch commented on Oct 9, 2019

    @reschresch
    Author

    I try run local on my server.
    Actually I use port 90:
    root@server ~ # curl -vvv https://mydomain.xx:90/version

    • Trying 123.456.789.123...
    • Connected to mydomain.xx (123.456.789.123) port 90 (#0)
    • found 148 certificates in /etc/ssl/certs/ca-certificates.crt
    • found 596 certificates in /etc/ssl/certs
    • ALPN, offering http/1.1
    • SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
    • server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates .crt CRLfile: none
    • Closing connection 0
      curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-cer tificates.crt CRLfile: none
      More details here: http://curl.haxx.se/docs/sslcerts.html

    curl performs SSL certificate verification by default, using a "bundle"
    of Certificate Authority (CA) public keys (CA certs). If the default
    bundle file isn't adequate, you can specify an alternate file
    using the --cacert option.
    If this HTTPS server uses a certificate signed by a CA represented in
    the bundle, the certificate verification probably failed due to a
    problem with the certificate (it might be expired, or the name might
    not match the domain name in the URL).
    If you'd like to turn off curl's verification of the certificate, use
    the -k (or --insecure) option.

  7. jmattheis commented on Oct 9, 2019

    @jmattheis
    Member

    Have you updated that server lately? maybe your certs in /etc/ssl/certs/ca-certificates.crt are outdated.

    Could you try updating these?

    $ update-ca-certificates
    

    See https://superuser.com/a/437377

  8. reschresch commented on Oct 10, 2019

    @reschresch
    Author

    Hello jmattheis,
    I have executed your command but under linux-CLI there is no difference. The message is the same I wrote yesterday.
    Today I try out the Windows-CLI and it runs perfectly. No problem to send a push-message, the init-procedure runs without problems from beginning to the end.
    On the smartphone I have to disable the checkbox the SSL-validation.
    For my better understanding: Is "my" error-message from the letsencrypt-certificate or is this the ssl-certificate? I read again which from the four letsencrypt-pem-files is the right one.
    With best regards,
    reschresch

  9. jmattheis commented on Oct 10, 2019

    @jmattheis
    Member

    Yeah, your letsencrypt certificate may not be valid or you linux server somehow thinks that it is. Using this cli with an unsecure cert would require #27

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions