Thanks for sharing this! I didn't realize you could bypass HTTPS restrictions built into modern browsers in this manner.
I would still *never recommend* this approach, even for intranet usage. It's obviously a massive security issue for any production quality system. As you rightly noted, it's a very bad idea since everything will be sent in plain text. This means that a malicious user on your intranet could sniff traffic to steal passwords and (possibly) even steal your authenticated session (via information found in unsecured cookies). So, good to know it's an option if people really want this. But, I can never recommend it for any production-like scenarios. :) HTTPS is required for your site to be secure. Anyone can generate a free HTTPS certificate using services like Let's Encrypt: https://letsencrypt.org/ ("certbot" tool) and there are plenty of guides out there around using Let's Encrypt with whatever webserver you choose (Apache, Nginx, etc). For example, EFF provides instructions for using/installing certbot for HTTPS based on your OS and webserver: https://certbot.eff.org/ Tim On Friday, November 18, 2022 at 9:22:06 PM UTC-6 [email protected] wrote: > Occasionally I see some posts in this list asking if it's possible to run > DSpace without having to go the HTTPS path and the answer is yes you can. > I'm attaching a confirmation which I received from this thread creator > (Chalew Tesfaye) but it never found it's way here, I'm also attaching a > video which I made tonight after spinning up a new server and installing > the latest DSpace 7.5-Snapshot on it just to let you know it works. > > Hope it help someone who needs it. > > [image: 2022-11-19_3-12-14.jpg] > > > On Saturday, February 26, 2022 at 7:57:31 AM UTC+3 Mohammad S. AlMutairi > wrote: > >> It's a very bad idea to run Dspace or any other service unsecure ( >> Traffic including login credentials can be sniffed very easily ) but if you >> insist on doing it It's possible to run it via HTTP ( See the setup that >> should work for you below ). The issue with the latest browsers builds ( >> Chromium based browsers and the rest of the gang ) is if the services run >> in a mixed mode specially downgrading from HTTPS ---> HTTP. but HTTPS >> <----> HTTPS or HTTP <----> HTTP Should work just fine. >> >> >> - You don't need a webserver for this to work so you must stop the >> webserver and disable it or even uninstall it if you wish. >> - The two points you see below must be done if you don't have a local >> DNS server for the dspace server and the clients accessing the dspace >> server to resolve the dspace server name to its IP address. >> - You need to tell the server about itself by adding a host entry >> into /etc/hosts file. As an example assuming the dspace server ip address >> is 10.0.10.10 and its name is dspace.intranet.net the entry in the >> hosts file should be ( 10.0.10.10 dspace.intranet.net ). >> - You need to tell the client/workstation how to reach the dspace >> server. You can add a similar entry as above into the client PC hosts >> file >> in Linux it should be in /etc/hosts and in Windows should be in >> C:\Windows\system32\drivers\etc\hosts .. >> >> >> in dspace.cfg or local.cfg set: >> dspace.server.url = http://dspace.intranet.net:8080/server >> dspace.ui.url = http://dspace.intranet.net >> >> Note that I'm using port *80* here. >> in config.prod.yml set: >> ui: >> ssl: false >> host: dspace.intranet.net >> port: 80 >> # NOTE: Space is capitalized because 'namespace' is a reserved string >> in TypeScript >> nameSpace: / >> # The rateLimiter settings limit each IP to a 'max' of 500 requests per >> 'windowMs' (1 minute). >> rateLimiter: >> windowMs: 60000 # 1 minute >> max: 500 # limit each IP to 500 requests per windowMs >> >> # The REST API server settings >> # NOTE: these must be 'synced' with the 'dspace.server.url' setting in >> your backend's local.cfg. >> rest: >> ssl: false >> host: dspace.intranet.net >> port: 8080 >> # NOTE: Space is capitalized because 'namespace' is a reserved string >> in TypeScript >> nameSpace: /server >> >> >> *Test the connection using yarn test:rest and then just build the >> frontend and once it finished the build process point your browser >> to http//dspace.intranet.net/ <http://dspace.intranet.net/> and it should >> work without any issue including the logging in.* >> >> >> On Friday, February 25, 2022 at 3:51:12 PM UTC+3 [email protected] >> wrote: >> >>> I tried a self-signed certificate, still I didn't get right. >> >> >> Here is how it should be done to work. >> >> - The two points you see below must be done if you don't have a local >> DNS server for the dspace server and the clients to resolve the dspace >> server name to its IP address. >> - You need to tell the server about itself by adding a host entry >> into /etc/hosts file. As an example assuming the dspace server ip address >> is 10.0.10.10 the entry in the hosts file should be ( 10.0.10.10 >> dspace.intranet.net ). >> - You need to tell the client/workstation how to reach the dspace >> server. You can add a similar entry as above into the client PC hosts >> file >> in Linux it should be in /etc/hosts and in Windows should be in >> C:\Windows\system32\drivers\etc\hosts .. >> >> You need to build a SAN certificate to satisfy the recent chromium based >> browsers. Chrome will generate an error if you use a common name only in >> the self signed certificate. >> >> 1) Create a san file call it san.cfg that contains: >> >> [req] >> distinguished_name = req_distinguished_name >> x509_extensions = v3_req >> prompt = no >> [req_distinguished_name] >> C = COUNTRY-NAME-HERE >> ST = STATE-OR-PROVINCE-HERE >> L = CITY-NAME-HERE >> O = ORGINZATION-NAME-HERE >> OU = DEPARTMENT-NAME-HERE >> CN = intranet.net >> [v3_req] >> subjectAltName = @alt_names >> [alt_names] >> DNS.1 = www.intranet.net >> DNS.2 = dspace.intranet.net >> DNS.3 = cms.intranet.net >> DNS.4 = smtp.intranet.net >> DNS.5 = idp.intranet.net >> DNS.6 = sp.intranet.net >> >> 2) Build a 10 years certificate with its key in the local directory using: >> a) openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout >> ./server.key -out ./server.crt -config san.cfg -extensions 'v3_req' >> b) chmod 600 server.key >> >> 3) Copy the files to its final location & add the certificate and its >> key to the webserver as usual. >> 4) During the frontend connection testing yarn test:rest the testing >> will fail with the following error ( Error: self signed certificate ) to >> overcome this error you must execute the two commands (a) and (b) you see >> below. It's good for testing the connection, building and starting the >> frontend manually but you need to add Environment="NODE_EXTRA_CA_CERTS=/ >> PATH-TO/server.crt" to the frontend systemd startup script in the >> [Service] section if that's how you are going to start the frontend during >> the boot. >> >> a) echo "export NODE_EXTRA_CA_CERTS=/PATH-TO/server.crt" >> >> /etc/environment >> b) source /etc/environment >> >> 5) Assuming the client is a Windows machine the final step to make all of >> this workable is to add the self signed certificate (server.crt) to the >> *Trusted >> Root Certification Authorities *using mmc.exe, certlm.msc or using the >> browsers themselves. In Chrome ---> Settings ---> Security ---> >> Manage certificates ---> Click on Trusted Root Certification Authorities >> and Choose Import. >> >> >>> Thanks in advance. >>> >> >> You welcome. >> > -- All messages to this mailing list should adhere to the Code of Conduct: https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx --- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/efcbb570-9f4b-43a9-b735-1a498eb48ab3n%40googlegroups.com.
