21–30 of 55 posts
What's the biz model ?
I hear what you're saying, but people DO just put stuff out there for it to exist and aren't necessarily looking to monetize it. Crazy I know :)
If it's just a redirect, isn't it going to be bypassed as soon as the first user shares the real URL?
I ran a similar service when In was in high school. People were using it to distribute links in public settings that were meant for small circle of folks. Lots of club newsletters were distributed this way. People also used it for selling files and things but as you've said it was trivial to defeat and only filtered out the least technical folks. It was surprisingly popular.
If it's just a redirect, isn't it going to be bypassed as soon as the first user shares the real URL?
I guess since you’re going to have to give a password to someone, you can tell them not to do that. Though I’m a bit confused why this is even needed. The sort of thing most people want accessible via a link, but only for certain people, tend to already have unpredictable URLs. I’m not sure how https://gaggledocs.com/documents/aboevdowugwhoaofh Is different from https://protectmylink.xyz/owndoavwyagdo + a password Es…
I would point out that this will likely be used 99% of the time by people who want to charge for access to content... that they don't themselves own. If you've ever wandered the skeevier parts of the internet (the parts that a teenager not yet experienced at writing search queries might find themselves on if they were trying to e.g. download a software crack/keygen), then you'll frequently find that the pages you lan…
Hypothetical design:
1. you generate a password-protected link for a base URL https://origin.example.com/foo — this gives you a generated link https://abc123.link-protector.example.com/ (where abc123 is the generated-link ID.)
2. All *.link-protector.example.com subdomains CNAME to a single service.
3. This service's backend is an auth-protected reverse-proxy. On each request, it checks for an auth cookie unique to the subdomain.
4. If the auth cookie is good (signed by the backend, non-expired), then you take the happy path, where all paths on the subdomain will proxy-rewrite to paths under the original path /foo of the original domain.
5. If you don't present a good auth cookie, then all paths on the proxy subdomain instead redirect to a special /proxy-cgi/auth route, that has an auth system mounted to it. On successful auth, that auth system backend sets the cookie for the subdomain, and then redirects you back to the original path you requested.
(Note that the distinct subdomains per link are necessary here, to stop a malicious user of the service from stealing the cookie of a sibling proxy. You could avoid this by only using one auth cookie for the base domain, and then having every request look up the userID from that auth cookie to map it to a set of links that userID has been authed for — but that's a lot more expensive architecturally than this sort of "the LB can figure it out on its own" design.)
With this hypothetical design, at least the protection wouldn't just strip itself off each time someone fills out the password. Re-sharing the base URL — or any other URL navigated to on the same site! — would just result in the person who receives it also needing to know the password.
I still doubt there's be many use-cases for such a service compared to a vertically-integrated platform like Gumroad/Patreon. People who want to sell the resource would likely still much prefer to use those, rather than stringing individual components together. But I suppose that a password-protected reverse-proxy service would at least let you e.g. turn a public-but-anonymous resource (e.g. a page on a Pastebin-alike) into a members-only resource for a group.
(Even better for that use-case, though, would be if the reverse-proxy service allowed not only password-based sharing, but invite-based or group-based sharing, where link viewers must SSO-authenticate to the reverse-proxy. This would be like Google's BeyondCorp Identity-Aware Proxy, but for stuff outside your GCP VPC, and with one-click setup.)
Earlier quoted context omitted.
I suppose it is the same concept as gumroad vendors. Most of them simply put an s3 url behind the gumroad paywall. Once you are done buying, the s3 url can be shared with anyone.
I think the S3 URLs typically expire after a bit, at which point a new one would have to be generated the next time you need to re-download.
[flagged]