GTK3 applications in a browser with https and basic auth
The topic of my today's note is strange. I'll start with the preface. One friend asked a question in our small telegram chat: “Colleagues, do you know any web terminals? And sometimes you need to go to your server from work, and then everything is cut according to the tonsils, "well asked and asked, everyone said" Yes, it seems we know nothing right away ", but because of the specifics of thinking, my question in my head was postponed . One night, I read the GTK3 documentation and came across GDK_BACKEND = broadway . A backend that uses HTML5 and websockets to display GTK3 applications. Something clicked in the brain, but it clicked strangely that for some reason someone seemed to need it, why I don’t remember anyone, either.
I lived with these clicks in my head, remembered to whom, even wrote to a person, but honestly said that when experimenting with a localhost, the password described in broadwayd mana doesn’t work (quote from mana “You can add password protection for your session by creating a file in $ XDG_CONFIG_HOME / broadway.passwd or $ HOME / .config / broadway.passwd with a crypt (3) style password hash. A simple way to generate it is with openssl: openssl passwd -1> ~ / .config / broadway. passwd "), and therefore, on the one hand, it seems like it’s a feature that people needed, but on the other hand it’s just that you can’t hang it up, well, somehow to hang up a terminal with your bare eyes on the Internet is clearly not our choice. I tried to proxy through nginx so that I could use https and basic auth (well, or with a client certificate, then I would like to go further), I saw a blank screen and abandoned it.
Tonight I remembered this and decided that I had to look at what was the matter, looked again at broadwayd's description and realized that I had it in websockets, because I was trying to proxy just proxy_pass, as to http.
As a result of scratching in turnips, everything worked out for me. Actually the description, based on the fact that gnome-terminal (and we will start it, along with other gtk you already have).
In the nginx config, add the location in which we have basic auth and in which we will proxy to our broadwayd
We enable basic auth for the localization so that strangers do not pass (the web server only works via https, so the good provider and others will not intercept us along the way), set the headers necessary for proxying web sockets, and change the timeout, because by default proxy_read_timeout is in nginx is 60 seconds, in the case of web sockets we are 60 seconds, this is trouble and sadness. Well, we indicate where broadwayd will be waiting for us. We
check the config by running nginx -t and do nginx reload. Under the user whose terminal we wanted, do broadwayd -a 127.0.0.1 &. We start broadwayd to listen on lo, by default it starts on port 8080, it was already set in nginx, which is proxied to it.
GDK_BACKEND = broadway dbus-launch gnome-terminal. Run the desired gnome-terminal.
We access our web server from a browser, enter the login password from basic auth and see the desired terminal in front of us ...
"
PS We have one minus, the clipboard does not work in applications running in broadway (we are not only a terminal, we can most applications using GTK3 so run)
PPS I do not propose a similar solution seriously on production, although if you use a client ssl certificate to ensure access security, why not, the solution will be as ± safe as ssh by key)
I don’t exclude that a similar approach can be used zovan to create something more useful than the gnome-terminal accessible from the browser.
PPPSYes. That there would be no questions about the strangeness of the tasks that I describe in my articles, I will say right away that, due to the specifics of my thinking, if a task in my area of competence runs before me, even by accident, then I will solve it, sooner or later, one way or another . Regardless of whether I or someone else really needs it or not.
I lived with these clicks in my head, remembered to whom, even wrote to a person, but honestly said that when experimenting with a localhost, the password described in broadwayd mana doesn’t work (quote from mana “You can add password protection for your session by creating a file in $ XDG_CONFIG_HOME / broadway.passwd or $ HOME / .config / broadway.passwd with a crypt (3) style password hash. A simple way to generate it is with openssl: openssl passwd -1> ~ / .config / broadway. passwd "), and therefore, on the one hand, it seems like it’s a feature that people needed, but on the other hand it’s just that you can’t hang it up, well, somehow to hang up a terminal with your bare eyes on the Internet is clearly not our choice. I tried to proxy through nginx so that I could use https and basic auth (well, or with a client certificate, then I would like to go further), I saw a blank screen and abandoned it.
Tonight I remembered this and decided that I had to look at what was the matter, looked again at broadwayd's description and realized that I had it in websockets, because I was trying to proxy just proxy_pass, as to http.
As a result of scratching in turnips, everything worked out for me. Actually the description, based on the fact that gnome-terminal (and we will start it, along with other gtk you already have).
In the nginx config, add the location in which we have basic auth and in which we will proxy to our broadwayd
location /trm/ {
auth_basic "closed site";
auth_basic_user_file /etc/nginx/htpasswd;
proxy_redirect off;
# websocket
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
# end websocket
proxy_read_timeout 86400;
proxy_pass http://127.0.0.1:8080/;
We enable basic auth for the localization so that strangers do not pass (the web server only works via https, so the good provider and others will not intercept us along the way), set the headers necessary for proxying web sockets, and change the timeout, because by default proxy_read_timeout is in nginx is 60 seconds, in the case of web sockets we are 60 seconds, this is trouble and sadness. Well, we indicate where broadwayd will be waiting for us. We
check the config by running nginx -t and do nginx reload. Under the user whose terminal we wanted, do broadwayd -a 127.0.0.1 &. We start broadwayd to listen on lo, by default it starts on port 8080, it was already set in nginx, which is proxied to it.
GDK_BACKEND = broadway dbus-launch gnome-terminal. Run the desired gnome-terminal.
We access our web server from a browser, enter the login password from basic auth and see the desired terminal in front of us ...
" PS We have one minus, the clipboard does not work in applications running in broadway (we are not only a terminal, we can most applications using GTK3 so run)
PPS I do not propose a similar solution seriously on production, although if you use a client ssl certificate to ensure access security, why not, the solution will be as ± safe as ssh by key)
I don’t exclude that a similar approach can be used zovan to create something more useful than the gnome-terminal accessible from the browser.
PPPSYes. That there would be no questions about the strangeness of the tasks that I describe in my articles, I will say right away that, due to the specifics of my thinking, if a task in my area of competence runs before me, even by accident, then I will solve it, sooner or later, one way or another . Regardless of whether I or someone else really needs it or not.
