8000 Support conditional date-based redirects · Issue #2431 · shlinkio/shlink · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Support conditional date-based redirects #2431

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
vaslv opened this issue May 5, 2025 · 6 comments
Open

Support conditional date-based redirects #2431

vaslv opened this issue May 5, 2025 · 6 comments
Labels
feature

Comments

@vaslv
Copy link
vaslv commented May 5, 2025

Summary

Introduce a feature that allows defining alternative redirect targets depending on the age of a short URL (i.e. time since its creation). This would enable dynamic redirect behavior based on whether a short URL is older or younger than a specified threshold.

Use case

This feature would be useful in various real-world scenarios, such as:

  • Limited-time promotions: A short URL can point to a promotional product page for a set period (e.g. 7 days), and after that period redirect users to a generic product or category page.
  • Event invitations: Before an event starts, a short link can show a registration page. After the event, the same link can redirect to a recap or video recording.
  • Temporary content: Share time-sensitive materials (e.g. beta downloads, trial access), and redirect to a permanent page once the content is outdated.
  • Early access vs public release: During an early access phase, the link leads to a limited-access page; after a certain date, it switches to a general release page.

This allows for greater flexibility while keeping the same short URL functional and relevant across time.
@vaslv vaslv added the feature label May 5, 2025
@acelaya
Copy link
Member
acelaya commented May 5, 2025

I reckon this is basically the same as date-based redirects, as proposed here #2101 (comment)

Using absolute dates rather than relative date periods would be more predictable, as you can change it at any point in time without having to re-calculate when was the short URL created and introducing all sorts of cumbersome checks.

It would still be possible to provide a relative-time-based UI that does the conversion, so when you seelect something in the lines of "in 7 days" it calculates what's current date + 7 days and sets that.

It would be similar to this kind of filter for short URLs and visits, where you select a relative time period but then a date range is sent to Shlink.

Image

Please, feel free to up-vote #2101 (comment)

@acelaya acelaya changed the title Support conditional redirects based on Short URL age Support conditional date-based redirects May 5, 2025
@vaslv
Copy link
Author
vaslv commented May 5, 2025

The idea of storing the date and time before or after which the redirect rule should apply completely replaces the concept of link age. I agree that this is a more convenient solution.

@vaslv
Copy link
Author
vaslv commented May 6, 2025

Is the ability to create redirect rules using a date currently in development, or can I take on the implementation?

@acelaya
Copy link
Member
acelaya commented May 6, 2025 •
edited
Loading

Nobody is working on this at the moment, but I won't be able to do reviews for complex functionalities for some time (weeks or months), as I'm currently focused on pushing Shlink Dashboard out the door.

If you still want to give it a try, make sure you implement every case as in independent condition, as described in #2101 (comment). In fact, providing separated PRs for every condition would be probably desirable, as it will make PRs more atomic and easier to review.

For reference, these are some examples of similar functionalities implemented in the past:

Make sure your PR provides a concise description of what's being implemented, and references to the relevant issues/discussions.

You will need to provide tests and make sure all static checks pass. Follow the instructions in CONTRIBUTING.md to get the project up and running locally, and see how to run those checks.

If you send a PR, I'll review it as soon as I have some time.

@vaslv
Copy link
Author
vaslv commented May 6, 2025 •
edited
Loading

Before proceeding with the implementation, I’d like to clarify a few points.

For the condition Date, do you mean precision up to the second? If so, in the context of URLs, I think it’s unnecessary to use exact comparison — having just two options, “Before” and “After”, should be enough. Also, I believe the comparison type can be used as a key, and the date and time as a value. That way, we’d only need a single new redirect condition. What’s your take on that?

Then the conditions would look as follows

{
  "defaultLongUrl": "https://example.com",
  "redirectRules": [
    {
      "longUrl": "https://example.com/1",
      "priority": 1,
      "conditions": [
        {
          "type": "date",
          "matchValue": "2025-10-10T06:00:00+02:00",
          "matchKey": "before"
        }
      ]
    },
    {
      "longUrl": "https://example.com/2",
      "priority": 2,
      "conditions": [
        {
          "type": "date",
          "matchValue": "2025-10-20T12:30:00+02:00",
          "matchKey": "after"
        }
      ]
    }
  ]
}

@acelaya
Copy link
Member
acelaya commented May 6, 2025

For the condition Date, do you mean precision up to the second? If so, in the context of URLs, I think it’s unnecessary to use exact comparison — having just two options, “Before” and “After”, should be enough.

Yep, I think you are right. There's probably no point on creating a rule to redirect someone from 2025-05-01T10:00:00 or later, when you can simply create a redirect that works after 2025-05-01T09:59:59 and mean the same.

Let's start with just two rules for "before" and "after". I may have thought on some reason for the other two at some point, but I don't remember now 😅. They could be added later if needed anyway.

Also, I believe the comparison type can be used as a key, and the date and time as a value. That way, we’d only need a single new redirect condition. What’s your take on that?

I thought about this, but using separate rules will make validation much simpler. The narrower the data the user has to send, the better. The matchKey should be avoided as much as possible, and it's there only because it may be needed for some rules.

@vaslv vaslv mentioned this issue May 7, 2025
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
feature
Projects
Shlink
Status: No status
Milestone
No milestone
Development

No branches or pull requests
2 participants
@vaslv @acelaya
0