DOMException: The operation is insecure #5

New Issue

2026-02-16T12:51:01-05:00

yindo commented

2026-02-16 12:51:01 -05:00

Originally created by @Orangian on GitHub (Sep 30, 2021).

Just self hosted an instance, but I can't login after onboarding as the firefox console always spits out:

DOMException: The operation is insecure. util.tsx:21:16
    Ot util.tsx:21
    o Form.tsx:69
    onSubmit Form.tsx:107
    ie index.esm.js:1099
    Preact 31
        k
        (Async: EventListener.handleEvent)
    E
        __e
        __e
        T
        O
        __e
        T
        O
        T
        O
        T
        O
        T
        O
        T
        O
        T
        O
        T
        O
        T
        O
        __e
        T
        O
        __e
        T
        O
        __e
        T

Now, I have no clue what this means, can anyone help?

Originally created by @Orangian on GitHub (Sep 30, 2021). Just self hosted an instance, but I can't login after onboarding as the firefox console always spits out: ``` DOMException: The operation is insecure. util.tsx:21:16 Ot util.tsx:21 o Form.tsx:69 onSubmit Form.tsx:107 ie index.esm.js:1099 Preact 31 k (Async: EventListener.handleEvent) E __e __e T O __e T O T O T O T O T O T O T O T O __e T O __e T O __e T ``` Now, I have no clue what this means, can anyone help?

yindo closed this issue

2026-02-16 12:51:01 -05:00

yindo commented

2026-02-16 12:51:01 -05:00

@Orangian commented on GitHub (Oct 1, 2021):

Possibly similar to livewire/livewire#1529, could be an issue with the fact that the Revolt server is running on HTTP but being proxied as HTTPS. In that case, is there anything I can do to fix this, or is this an issue on Revolt's end?

@Orangian commented on GitHub (Oct 1, 2021): Possibly similar to livewire/livewire#1529, could be an issue with the fact that the Revolt server is running on HTTP but being proxied as HTTPS. In that case, is there anything I can do to fix this, or is this an issue on Revolt's end?

yindo commented

2026-02-16 12:51:01 -05:00

@insertish commented on GitHub (Oct 10, 2021):

You should be exposing all services as either in a HTTP or HTTPS context, you can't mix and match except when going from HTTP -> HTTPS (insecure client origin to secure server, but you lose features this way).

@insertish commented on GitHub (Oct 10, 2021): You should be exposing **all services** as either in a HTTP or HTTPS context, you can't mix and match except when going from HTTP -> HTTPS (insecure client origin to secure server, but you lose features this way).

yindo commented

2026-02-16 12:51:01 -05:00

@Orangian commented on GitHub (Oct 13, 2021):

Sorry, how would I go about doing this? I have set all services in the .env file to be accessible under HTTPS, however, when I attempt to actually connect to them, the revolt server itself is running under HTTP.
For instance, exposing the REVOLT_APP_URL under https://192.168.200.47:5000 nets me an SSL certificate length error when actually connecting there (as it is attempting to serve HTTP requests over an HTTPS connection), while connecting under http://192.168.200.47:5000 gets me a successful connection, but without working logins.

@Orangian commented on GitHub (Oct 13, 2021): Sorry, how would I go about doing this? I have set all services in the .env file to be accessible under HTTPS, however, when I attempt to actually connect to them, the revolt server itself is running under HTTP. For instance, exposing the REVOLT_APP_URL under https://192.168.200.47:5000 nets me an SSL certificate length error when actually connecting there (as it is attempting to serve HTTP requests over an HTTPS connection), while connecting under http://192.168.200.47:5000 gets me a successful connection, but without working logins.

yindo commented

2026-02-16 12:51:01 -05:00

@insertish commented on GitHub (Oct 14, 2021):

Specifying https: does not change anything, these variables are used by the client to connect to the server, the server doesn't actually do much else with them.

You need to configure a reverse proxy pointed at each service which allows it to run over HTTPS.

@insertish commented on GitHub (Oct 14, 2021): Specifying `https:` does not change anything, these variables are used by the client to connect to the server, the server doesn't actually do much else with them. You need to configure a reverse proxy pointed at each service which allows it to run over HTTPS.

yindo commented

2026-02-16 12:51:01 -05:00

@Orangian commented on GitHub (Oct 14, 2021):

Ah, I see there has been a miscommunication. As I attempted to state in an earlier comment, every service is proxied through apache over HTTPS with a valid certificate, and the error still persists.

@Orangian commented on GitHub (Oct 14, 2021): Ah, I see there has been a miscommunication. As I attempted to state in an earlier comment, every service is proxied through apache over HTTPS with a valid certificate, and the error still persists.

yindo commented

2026-02-16 12:51:02 -05:00

@nadiamoe commented on GitHub (Nov 30, 2021):

It might be possible that you changed all URLs in the config file from http to https but, like me, forgot to change the websocket schema from ws to wss. That fixed the error for me :)

@nadiamoe commented on GitHub (Nov 30, 2021): It might be possible that you changed all URLs in the config file from `http` to `https` but, like me, forgot to change the websocket schema from `ws` to `wss`. That fixed the error for me :)

yindo commented

2026-02-16 12:51:02 -05:00

@Orangian commented on GitHub (Dec 3, 2021):

That fixed it, thanks! (As far as I can tell, mongo is refusing to work right now, but I'd expect to get that error beforehand.)

@Orangian commented on GitHub (Dec 3, 2021): That fixed it, thanks! (As far as I can tell, mongo is refusing to work right now, but I'd expect to get that error beforehand.)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: stoatchat/self-hosted#5