rippled
rippled copied to clipboard
Allow redirect for browser connections
The peer port accepts HTTP connections but if someone connects with browser they seen only "Forbiden" message. A config option allows administrator to redirect to a webpage.
For example the servers of an exchange could load the exchange page or some other status page.
High Level Overview of Change
Context of Change
Type of Change
- [X] New feature (non-breaking change which adds functionality)
- [X] Documentation Updates
Please check at least one of the "Type of Change" checkboxes, or add a new one if none of the existing ones seem appropriate.
IMO, this will only work if the ‘rippled’ instance has a valid certificate. I don’t think you can redirect without that first being evaluated.
Please check at least one of the "Type of Change" checkboxes, or add a new one if none of the existing ones seem appropriate.
OK I checked.
IMO, this will only work if the ‘rippled’ instance has a valid certificate. I don’t think you can redirect without that first being evaluated.
Yes I think so too because the browser may not honour redirecter 301 from unsecure connection. But this is not problem I think because probably only helpful from the large server pools like xrpcluster ripple and your alloy and maybe by exchanges that run servers.
This funcionality is helpful because if someone connects with browser they may see helpful website instead of weird one word error.
It would be lovely to have this. However, it would require a restart of rippled
for any certificate change - and for operators such as hubs or exchanges, that restart could be at a very inconvenient time. Moreover, this operation would have to be performed on each server in a cluster :sweat_smile:
xrplcluster itself is meant for websocket connections. It is not a hub pool, and has backend peers from multiple operators, including me.
It would be lovely to have this. However, it would require a restart of
rippled
for any certificate change - and for operators such as hubs or exchanges, that restart could be at a very inconvenient time. Moreover, this operation would have to be performed on each server in a cluster sweat_smile xrplcluster itself is meant for websocket connections. It is not a hub pool, and has backend peers from multiple operators, including me.
I do not understand why the restart is needed. If you alreayd have a certificate set that is not the automatic certificate generated by the code then you already need to restart when the ceritifcate expires. That is a problem when you update a Let'sEncrypt certificate becaue its short life, but other certificates are ok for 1 or 2 or more year.
Yes its true that you must do this config change on every server but better cluster support might be able to fix that by setting the config on the full cluster instead on a server at a time. Maybe something for the future.
I used xrplcluster as example as I don't know whow runs professional servers other than Ripple and zaphod.
To be clear, I don’t find anything inherently wrong with this pull request. I’m only pointing out that operators should be aware of the additional administrative responsibilities of using valid certificates to allow the redirect.
@a-noni-mousse (or @alloynetworks ), could you draft some documentation that would help operators be aware of those responsibilities?
It could be a Markdown file here in the rippled repo, or on XRPL.org (xrpl-dev-portal).
@a-noni-mousse how would you like to move this forward?
I think its okey to merge @intelliot what do you mean documentation for additional responsbilities? i don't understand what extra you want me to do.
Please reach out to @alloynetworks to clarify:
To be clear, I don’t find anything inherently wrong with this pull request. I’m only pointing out that operators should be aware of the additional administrative responsibilities of using valid certificates to allow the redirect.
https://github.com/XRPLF/rippled/pull/4441#issuecomment-1454539544
@a-noni-mousse if you'd like to move this PR forward, please document the change so that server operators are "aware of the additional administrative responsibilities of using valid certificates to allow the redirect." See the comment above.