Open maintainance links in new tab

[kub3let]

🛡️ Security Policy

• I agree to have read this project Security Policy

Description

Currently urls are rendered as a href and are clickable, but if you click on them you move away from uptimekuma.

I would be great if these are rendered with target="_blank" to open in a new tab.

👟 Reproduction steps

Create a manual maintainance with a link to another site e.g. https://example.com

👀 Expected behavior

Link opens in a new tab

😓 Actual Behavior

Link opens in current tab

🐻 Uptime-Kuma Version

1.23.13

💻 Operating System and Arch

Docker

🌐 Browser

Chrome

🖥️ Deployment Environment

not relevant

📝 Relevant log output

No response

[mahenoorsalat]

I am willing to work on this issue ... as I have stron foundation on front-End technologies @kub3let can you please assign me this work .. looking forward to your response

Thank you:)

[CommanderStorm]

We don't assign users to issues.
Firstly, because I can only assign the issue poster and contributors and secondly because I don't think that bureaucracy is nessesary ^^
Just drop us a PR 😁

[mahenoorsalat]

okay sure @CommanderStorm

[VarPDev]

@kub3let can you tell me in what part of uptime kuma maintainance you insert the link?

[kub3let]

@VarPDev sure it's in the description field, to replicate:

https://status.your_domain.com/maintenance

Foo bar

We are under maintenance please check https://example.com/ for more information

[VarPDev]

@kub3let
The problem is that kuma use marked library to convert text in html.
Also passing <a href="https://example.com/" target="_blank">example</a> the marker library doesn't work.

So I think you have to open a issue to marker library and when they solve this, you can open a link in other tab using this syntax:
<a href="https://example.com/" target="_blank">example</a>

[kub3let]

I don't think changing marked.js upstream is the right approach here.

It does expose the rendering functions so can be adjusted in uptimekuma, e.g.

// Create a new renderer instance
const renderer = new marked.Renderer();

// Override the link function
renderer.link = function(href, title, text) {
  const link = `<a href="${href}"${title ? ` title="${title}"` : ''} target="_blank" rel="noopener noreferrer">${text}</a>`;
  return link;
};

// Initialize marked with the custom renderer
marked.setOptions({
  renderer: renderer
});

// Example Markdown input
const markdownInput = '[Google](https://www.google.com)';

// Parse the markdown
const htmlOutput = marked(markdownInput);

console.log(htmlOutput);

Another approach would be a js document load handler which updates all a href under .shadow-box > .content, but that's
more a hack and should be used as last option.

I can take a look myself If i find time to setup the dev environment, but I would like feedback from the maintainers first which approach we wan't to do. @CommanderStorm

[VarPDev]

If we prefer that by default it should be put to all links target="_blank" then it is not the right approach.
But I would prefer to be able to choose whether to have a brank link or not.
Since the marked library already supports the use of html but has a bug on creating the link I would open a ticket there.

Currently marked if you pass him this link: <a href="https://example.com/" target="_blank">example</a>
He creates an html like this: <a href="https://example.com/">example</a>So maybe it is wrong how marked creates the html.

what do you think?

[kub3let]

Striping the tags is most likely a security feature, e.g. strip js etc. from it. So that's probably why target get's removed.

Either way I don't think people should need to write html with target blank etc., they should just paste an http link and it should be rendered accordingly with target=blank.

Limiting it only to the maintenance content makes sense, but I don't think it hurts doing it globally as well, I would prefer this to be the default.