Amrayu78 Thanks for the request - I understand the concern about PB links being reshared by users who shouldn't have access.

Just to clarify: PB links currently point to external file hosts, and are only visible to logged-in users. That part works as intended - we’re already restricting visibility.

However, once a logged-in user clicks the link and lands on the external file, we lose all control. The external host (e.g. Gofile.io, Dropbox, Google Drive, etc.) doesn’t enforce any membership rules -so even if we force authentication before showing the link, the user can still:

Technically, there’s no way to enforce access restrictions once the external link is exposed. That’s a fundamental limitation of using third-party storage - WordPress can control who sees the link, but not who uses it.

Hosting files internally would allow tighter control, but I understand that’s not an option, and that’s why external storage was chosen in the first place.

To sum up:

If needed, we could add a warning to discourage sharing, but technically, there’s no way to force authentication on external files.

Perhaps I have misunderstood the issue? Please let me know.

Max Romanchenko yup, you understood correctly. And I know about the complexities of this, but I think gofile has some APIs that we can utilize to reauthenticate again.

Adding another popup will not prevent this behavior.

Max Romanchenko I checked ChatGPT for some possible solutions. Great — since you’re using Gofile, the best way to reauthenticate users before they can access links is to never expose the direct Gofile URLs, and instead serve them through your own gated system. Here’s how you can do it:

⸻

✅ Option 1: Use an Auth-Gated Redirect Page

🔧 Step-by-step Setup:

1. Don’t display Gofile links directly

Instead of showing something like:

Show:

2. Create a route on your site, e.g., /download/[slug]

This page:

• Checks if the user is logged in.

• If not logged in → redirect to login page.

• If logged in → use Gofile API to fetch the actual file link, then redirect or stream.

3. Optional: Log access (which user downloaded what and when).

⸻

✅ Option 2: Dynamically Generate Gofile Direct Links with Expiry (API Approach)

While Gofile doesn’t have signed expiring links like AWS, you can:

• Store the folderToken securely (you already have this based on previous chats).

• Use your server to fetch the file link on-demand via the Gofile API:

You can dynamically fetch the direct download URL when a valid member requests it.

⸻

✅ Option 3: Serve File Through Your Server

If you want full control:

• Your server downloads the file (or streams it live) from Gofile and serves it to the user.

• This prevents hotlinking but adds server load.

Example (Python Flask-style pseudo-code):

@app.route("/download/<file_id>")

@login_required

def download(file_id):

gofile_url = fetch_gofile_link(file_id)

return redirect(gofile_url)

⸻

Optional Extras:

• ✅ Add rate limiting per user

• ✅ Add reCAPTCHA for bot protection

• ✅ Add timestamp/tokens in the redirect URLs for added security

• ✅ Obfuscate file IDs if you’re worried about brute forcing

⸻

Let me know if your site runs on WordPress, Next.js, Flask, etc., and I’ll give you a ready-to-copy implementation.

Amrayu78 Thanks again for sharing those ideas. I’ve reviewed them carefully, and while they’re technically sound in isolation, they don’t fully align with our current setup.

Most importantly, these suggestions focus on Gofile only, while our PB links also include other external services like Google Drive - so any solution needs to be approached holistically.

You're absolutely right that the core issue is link exposure. Once a user sees the direct link, whether to a file or a folder, they can share it, download it, or reupload it elsewhere. Even if we stream the file securely, once it’s on their device, it’s out of our hands.

So the real goal isn’t to protect the file it’s to avoid exposing the link in the first place. That’s where Option 2 (API-based access) becomes relevant.

To make that work properly:

We'd need to store the Gofile content ID and folderToken in post meta - not the public URL.

When a logged-in user requests access, call the Gofile API to fetch the list of files in that folder.

Then we'd present those files in a controlled UI (e.g. download buttons), without ever showing the real Gofile link.

This approach would require:

Some fallback strategy for other hosts like Google Drive

It’s not trivial, but it’s the only realistic way to reduce link abuse without changing the hosting model.

This kind of integration is theoretically possible, but it would require a deeper look at Gofile's API capabilities, especially around folder listing and file access.

Please let me know what you think about this. I am currently working on the statistics section, so once we have clarified all the details, we can make the right decision regarding the protection of PB links.

Max Romanchenko Let's go forward with this >>>

We'd need to store the Gofile content ID and folderToken in post meta - not the public URL.

When a logged-in user requests access, call the Gofile API to fetch the list of files in that folder.

Then we'd present those files in a controlled UI (e.g. download buttons), without ever showing the real Gofile link.

This approach would require:

A paid Gofile plan (for API access)

A custom integration to handle folder contents, file selection, and download flow

Some fallback strategy for other hosts like Google Drive

----

I have a paid gofile plan with API access.

If needed, I can rehost everything on gofile so we don't need to worry about Google Drive.

I know this is a major task, but I think we're ready for this next phase to protect the links on the site. If people reshare the files outside of that, I realize that's out of my hands, but they would have to reupload and do some work themselves instead of leeching from the links on the site.

Amrayu78

That sounds great , thanks for confirming.

Before we move forward with the integration, I’d like to take a closer look at how Gofile’s API works in practice.

Specifically, I need to confirm whether we can reliably extract the necessary identifiers (like contentId) from the existing PB links, or if we’ll need to adjust how those links are stored going forward...

To begin testing, could you please send me your Gofile API token by email?

Max Romanchenko Email sent.

Amrayu78 Okay, I think it's ready for testing. Phew. For now, it's only available to administrators (the red anchor in the episode table and the yellow widget on the movie page are only for testing purposes). External links are completely hidden. The download source is https://drama-otaku.com/). Downloading is only available to authorized users on the site. Proxying of real Gofile links. A fallback for Google Drive links has also been implemented.

Max Romanchenko Thanks Max! I've tested this on desktop and it's working great so far!

A few suggestions/questions:

Thanks! This is great work so far. I'm happy that you were able to resolve the issue.

Amrayu78

Sorting - yes, that's a nice improvement. I'll do that.

Thank you!

Although downloading still periodically sends me to GoFile... I need more time to figure out what's going on. It seems to me that a guest user is created on GoFile every time a request is made. I need to test it some more.

Max Romanchenko yes, mobile is still exposing the link. It acts like a redirect which opens up the mobile browser. I tested on iPhone and it opens gofile on safari. Mare tested it on her mobile device and it opens up on Firefox.

Amrayu78

This was a serious challenge. I threw absolutely everything at it, but every approach led to a redirect on the first access. Eventually, I contacted GoFile support to ask if this was expected (see the conversation below).

Their response sparked an idea - I built on it, and here’s the solution: we now generate temporary direct-access links that completely bypass GoFile's main site. These links live for 1 hour by default (this can be changed).

Now, when the user clicks Download a unique link is created just for them - no redirects. Works smoothly even on mobile.

Please check it out.

P.S. Sorting by criteria is still in progress.

My request: __________

Name : Max

Email : max.workingwell@gmail.com

Hello GoFile Support,

I'm developing an integration using your API with my premium account. To enhance security, I'd like to clarify:

I’m trying to use your API to download files programmatically. The API returns a direct download link (e.g., https://store5.gofile.io/download/...), but the first click redirects to https://gofile.io/d/%7BfileId%7D, while subsequent clicks download the file directly.

Is this the intended behavior?

Is there a way to bypass the initial redirect and download files directly on the first request?

Are there additional headers/parameters (e.g., session tokens) required to stabilize downloads?

I’d appreciate any guidance to ensure compliance with your policies.

My goal is to protect files from being shared by users. I don't want them to see where the file is located.

Thank you!

Gofile Technical Support:_______________________

Hello,

When you request a download link from the API, only the source that made the request can download the file directly. If you share that link with someone else, they will be redirected to the download page, where they they will make their own API call to get authorization to download.

If you want a link that anyone can use to download without visiting the Gofile website, you need to create a direct link to the content. These types of links are designed for this purpose. You can create them directly using the API.

Let me know if you have any questions.

The Gofile Team

July 26, 2025 at 1:11 PM, "Gofile" <contact@gofile.io> wrote:

_____________________________________________________________

Max Romanchenko thanks for working with the gofile support team on this. For this direct link feature though, will this specific usage (direct links) charge more? I know there’s a certain threshold for this. Is it possible to only implement this for mobile users? And for desktop use the old method you had implemented initially?

Amrayu78 No, this doesn't affect costs at all - it's just an API method. GoFile confirmed it’s the same as if a user clicked the old direct link and downloaded a file.

Here’s official reference:

The redirect was always there, even on desktop - we just didn’t notice because links had been visited before. For new users, GoFile redirects to a page like https://gofile.io/d/... first, regardless of device.

So yes - the current method is the correct and reliable way to deliver files.

The previous method contained errors. It provided raw links that could cause redirects.

Don't worry, everything will work as it should. This will not affect the price or how files are stored or downloaded. Everything will remain the same. That's what the API is for.

Max Romanchenko Got it. Thanks for clarifying. I just remember there's something like direct links in the gofile interface and it had a separate transfer quota.

I will test it and report back! Thanks so much for your work on this.

Amrayu78 Thank you! This once again confirms that what is possible with UI tools is also possible with API. This is a great service, I am amazed by its scale. I hope this will not change.

The limits are not publicly disclosed for security reasons, but I think they will easily withstand the requests you have.

Max Romanchenko Thanks for checking. Let's push this live!

One question though, if people have the existing links, they can still directly access them right? It's just from now on, they can't see the gofile links?

Max Romanchenko I'm just thinking out loud, but is it possible to log the usernames of those who click/download the links now? Let me know if this is possible or not?

Also I've used gofile for at least 2-3 years and it has been pretty stable for the most part. There is another file storage called pixeldrain that's similar.

Amrayu78

One question though, if people have the existing links, they can still directly access them right? It's just from now on, they can't see the gofile links?

–– Yes, that's right.

I'm just thinking out loud, but is it possible to log the usernames of those who click/download the links now? Let me know if this is possible or not?

–– Currently, this is not possible. Neither we nor Gofile track this (only the total number of downloads is available from the API). But it is definitely possible to implement. I need to think about some kind of storage that will store this information. What fields would you like to save? Date, username, file name, right?

We can go live now or implement tracking and then go live later. What would you prefer?

Max Romanchenko let’s go live for now and implement tracking for the next phase. But yes, date, username, and file name.

Amrayu78 Got it. It's already live.

Amrayu78 I added sorting by title and date. Please check it out.

Amrayu78 – But yes, date, username, and file name.

I'm working on the logs. Do you think we should also save Drama, Special, and Movie? So we know where the user downloaded the file from, which page.

Amrayu78 And one more thing. I need to understand what the end result will be. Will it be the same as tracking for a subtitle project? (View Downloaders)

Or should it be a separate admin page like a log - who downloaded what and when.

The architecture depends on this.

Thank you.

Max Romanchenko Yes, we should get the page where the file is from too.

Max Romanchenko Let's keep a log on the page itself in another tab which is only available/viewable to admins. I'm thinking it will be very long, hundreds of entries per episode or file.

Amrayu78 Maybe something like this? Under each file, if there are users who have downloaded it, a button with a list is displayed (available only to admins).

Max Romanchenko I think this is fine. Can we also add this in the dashboard for admins too like we have for subtitle downloads?

Max Romanchenko also going back to the original request for this feature, can you also implement the gofile link hiding for pages on subtitle projects under the PB?

Here's an example: https://drama-otaku.com/subtitle-project/ai-no-gakkou-learning-to-love-nf/

Some contributors have started using this field to redirect users as well, so you'll have to account for that behavior too. There's not a ton of subtitle projects that have this, but I think we should port the feature over to it too for consistency and security.

Thanks.

Amrayu78

Can we also add this in the dashboard for admins too like we have for subtitle downloads?

–– But we don't have such a page for subtitle downloads. We have Tampered File Analysis, but it's not the same thing...

– can you also implement the gofile link hiding for pages on subtitle projects under the PB?

–– I have made changes, please check.

Max Romanchenko I mean in the front-end dashboard. We have something to search for downloads of a user here:

Max Romanchenko this is working! Thanks.

Amrayu78

Oh, thanks for the screenshot, now I understand.

My additional questions:

Max Romanchenko can we integrate it with the existing downloads page (in the screenshot). Maybe add some filters, default view is all, then for subtitles and one for raws.

Amrayu78 That's an interesting idea, I need to think about it. First, I plan to do what's in the screenshot

And then I'll work on the Downloads page. But I think the All tab will be problematic because it has different storage and display sources. It's easier to make two tabs:

I assume that users will also see their raw downloads, right?

Max Romanchenko you can put it into 2 tabs within Downloads if it's problematic.

Yes, users should be able to see what they've downloaded before.

Amrayu78 Thank you for confirming. We may revisit this later. Now that we will be storing raw download logs, it may be worth reviewing the subtitle log storage system (I'm not sure yet, as there will be tens and hundreds of thousands of entries)

Amrayu78

Everything is done.

Some additional techniques may be applied in the future if there is too much data. For example, storing only data for the year in the database and archiving the rest in csv, but it is too early to talk about this yet.

Please check it out.

Max Romanchenko looks great!

One minor update: Downloads are now divided into subtitle downloads and raw downloads in the user profile.

Can we rename these tabs under Downloads to:

Subtitles (with an "s" at the end) and Raws change it to-> Pirate's Booty (RAWs is only for video files, but I realize there's also some random jp subs in the gofile folders itself)

One other update: Can you not show the "View Downloaders" link if there's no downloads yet? This is similar functionality on the Subtitle Project pages, the "View Downloaders" link doesn't show until there's at least 1 downloader to show data.

Amrayu78

Thank you! I have corrected the text.

Regarding the button - it's a bit different from what we use in our subtitle projects. Please take a moment to re-read my previous message (the first item in the list), where I explained the reasoning in more detail.

Since we don’t store external files ourselves, checking whether users have downloaded a specific file requires triggering a verification for each one individually. That means when the admin modal loads, it could result in multiple simultaneous checks, which becomes costly - especially when there are many files, like here:

Right now, checks are triggered via ajax only after the button is clicked. My concern is that as logs grow, these "was this file downloaded" checks could start generating unnecessary requests.

That said, if you'd prefer the button to be hidden, I can go ahead and make that change.

Max Romanchenko let's just leave it as-is then. Thanks!

Max Romanchenko One more fix: No raw downloads found.

Change to "No downloads found."

Amrayu78 Fixed.

Max Romanchenko I think we're good to go with this. One question though, are you able to change the folder short URLs to a new one using the API? I'm a bit paranoid that some people have saved URLs and are still sharing them publicly. Thanks.

Amrayu78 Unfortunately, we can’t change the short link https://gofile.io/d/XXXXX - it’s permanently tied to the folder's unique ID. Even if it were technically possible, links already stored in episodes/movies fields would still point to the old one, so we'd have to update every reference manually.

But I had another idea on how to make this possible. I wrote to support and they confirmed it. Here is our correspondence:

Here is my email:

Hi GoFile team,

We’re using your API to serve file download links securely via our website backend.

We’d like to confirm:

Can we set a folder to non-public (private) and still use the API to retrieve direct download links for the files inside it?

This would help us protect shared links while maintaining controlled access through our backend.

Thanks in advance!

_____________________________

Here is their response:

Hello,

If you are using the direct link feature, yes, it will work even for a folder that is not set to public.

If that’s not the case, please let me know.

________________

FOR EXISTING FOLDERS

This means you need to make all the folders currently used for Drama Otaku private. This means that even if a user has a link such as https://gofile.io/d/xxxxx, it will be closed to public access (except for you as the owner). This is the best and most reliable solution.

I tested it (made the folder private) and it works. Unfortunately, each folder will have to be done manually. Of course, I can add a condition to the existing code: if the folder is not private, make it private. But this code will only work when the user clicks on the anchor (i.e., when requesting the contents of the folder). Therefore, this method is not very reliable, as many folders will be publicly accessible until someone first requests their content. In addition, your account may contain folders that should remain public.

FOR NEW FOLDERS

Please note that when creating new folders, you need to temporarily make them public in order to obtain a unique URL:

https://gofile.io/d/xxxxx which is issued when you make the folder public and which must be saved in the meta field of the episode or movie.

Then, once you have copied it and saved it on the site, you can make the folder private again.

_____

Please check if this solution is suitable. In any case, I am glad that we have found a way to further protect files from direct access.

Max Romanchenko Thanks Max! I set the links for summer 2025 all to private and tested a few of them and they are still working from Drama-Otaku.com.

You don't need to add a condition to set a folder to private, I'll go through and gradually set things to private and will continue doing this from now on.

Thanks again for brainstorming and reaching out to gofile support to come up with a solution. It's greatly appreciated!

Amrayu78 I'm happy to help. You made the right decision to do it manually, as it gives you more control. I hope there aren't thousands of folders... In any case, if you need anything, please let me know.

Amrayu78 I have some news, just keeping you in the loop.

Here is our correspondence.

__________________

My email:

Hello, GoFile team!

Issue:

When getting a direct link via /contents/{file_id}/directlinks, any # symbol in the filename isn't URL-encoded to %23. This breaks the download link because browsers interpret # as a fragment identifier.

Current behavior (Is this expected?):

Returns:

https://.../direct/123/#filename.mkv

(404 error - browser ignores everything after #)

Expected behavior:

Should return (like /contents/{file_id} does):

https://.../direct/123/%23filename.mkv

Temporary fix:

We're manually replacing # with %23.

I just want to make sure that I am doing the right thing and that this is the expected behavior.

Thank you in advance!

________________________

Gofile's response:

Hello,

Thank you for your email.

You are correct; the URL was not encoded in the response of the link creation. However, it is correctly encoded when retrieving the link from /contents/{contentId}.

We have fixed it, and it should be live in the production environment within an hour at most. Please let us know if that resolves your issue.

Thank you.

_________________

“Failed to get file information from GoFile.”

It is not yet known what caused the error. The API returned some kind of non-standard response. It may be a glitch. I added extended logging for such cases in order to understand what is happening here.

I also removed the mention of GoFile in case of an error for users.

3.I see some users complaining that they cannot see subtitles in the new interface. I can add sorting by file type, if necessary (or by size, since subtitles are always smaller than videos), to help users find the files they need more easily.

Max Romanchenko Thanks for following up on this.

I'll check on number 2 to see if it's an issue still.

Number 3, some subtitles are in a separate folder so I just added it to the first episode. I'll do a bit of clean-up when I can so it's not so messy.

Amrayu78 Okay, got it!

So, for now, there's no need to add a new sorting type?

Max Romanchenko I think if people sort by name it'll be fine.

Max Romanchenko So this new method does cost a bit more money, I prepay, so I've been checking the account every day. This new method costs about $5~7 a day or so. The bandwidth is charged by gigabyte when direct links are used.

Can we revert it back to the code that you had previously? Or maybe for web, we revert it back, and for mobile, we can use the existing generate link/download link format.

I'm just trying to cut as much costs as possible so I can pay you more lol

Amrayu78 Let's find out what exactly is spending your budget. GoFile does not publicly disclose API limits, so we don't know exactly what is causing this. It is certainly related to the API, but it is not clear exactly what.

Here's what I suggest:

Reverting everything back is problematic at the moment, as there was a reason for all these changes. Let's not panic. I will first make the changes, contact support about the impact of the number of direct links on the cost (you can also write to them), and then we will see what to do next. Thank you, I don't want to use up your budget either, but the goal was to hide the links.

Max Romanchenko Before this direct link method, you had different code which worked on desktop, but not on mobile. I am fine eating the costs if we can't find a way to hide the links though. But if we can find some way to avoid it, or like you said, only generate one link, then perhaps itll be better. Thanks!

Amrayu78 I wrote to Gofile support and am waiting for their response. While we wait, I changed the download logic as we discussed. Now the link is generated once, and if it exists, it will be immediately available. If it does not exist yet, the user will be prompted to generate it (again, only once). This will reduce API requests by hundreds of times.

It would be great to cache the contents of the folder when we click on the anchor without requesting the API. But that's the next possible step. However, this requires your approval. I asked Gofile support if there is an API that notifies whether the contents of the folder or the folder itself has changed, but I don't think there is.

Therefore, if requesting the contents of the folder is expensive, we can cache it ourselves for a reasonable amount of time so that users do not encounter outdated content. The cache will also need to be cleared when generating the link so that the cache is up to date. This is quite tricky, but it will help if the content of a drama is requested by many users - we will be able to return the link without even referring to the API.

But the cache is an additional layer, as you know, and can be quite tricky... Let's wait for a response from support and, in the meantime, please test the modified download logic.

Max Romanchenko looks like its working okay for now. I'm attaching the credits I have right now. Tomorrow I can check again to see what it changes to.

Let's wait to see what gofile support says and then we can discuss more.

Amrayu78 Thanks for the info. Our goal is to minimize costs as much as possible while keeping the new download method from Drama Otaku.

On average, there are about 1,000 downloads per day. Please note that the number of direct link generations will decrease over time (I still don't know if this affects the cost or not), as currently almost no files have direct links. But this will change over time as people start downloading files and forming direct links.

Max Romanchenko Before we would get unlimited bandwidth if the short link was shared and users went to that gofile page.

With direct links, I think we're getting charged by GB transferred via this method.

Amrayu78 I understand, but if that's really the case, it's a bit unfair, in my opinion. API exists precisely to do something without going to the site itself, that's the whole point. Usually, a premium token should allow you to use higher limits than a free one... After all, the traffic has remained the same, only the download method has changed...

Okay, let's wait a little.

Max Romanchenko I think it’s that way because the APIs came later. Also the site itself has ads so it offsets the costs? So it’s a bit of a weird situation or business model.

Amrayu78 I spoke with support... They confirm your idea - that you pay for traffic using direct links. But these links are the only way to hide where the files are stored.

Here is the full correspondence: (it's too long to publish here):

Max Romanchenko Thanks for sharing the correspondence. What about the initial implementation you used without the direct links? There was a bug with mobile users getting the link exposed, but it was working okay with desktop users. Is that a possibility?

Amrayu78 Let me explain in more detail what was done initially.

Yes, you're right - I didn't use direct links in the initial version. That version hasn't been preserved, but that's not a problem. Now we have the full picture, and I can make the necessary changes after consulting with you first.

Regarding the bug: as it turned out during further communication with support, this is not actually a bug. It’s expected behavior - not only on mobile devices but also on desktop. You didn't encounter it because you were logged in and had already accessed a specific folder. I spent a lot of time on the tests and can confirm this. If you test this in incognito mode with new folder (the one you haven't visited recently), it doesn’t matter whether you're on a PC or mobile - when you try to download such a link for the first time, you’ll be redirected to the Gofile site. This behavior is documented in the API and was confirmed in the correspondence with support. So, you don't pay for such links - the traffic is charged to the person who downloads the file. These links may not always work (for example, if the user has exceeded their limits).

If it’s not a problem to show users the Gofile page first and then redirect them back, we can discuss that. What do you think?

The only downside to the current implementation is the cost, unfortunately.

Here is an example of a link (not direct) from the API response. I will delete it once you have tested it.

As you can see, this link looks direct and should lead to the file. But there is some clever logic behind it. When you first click on this link, GoFilemust identify you, create a temporary token if there isn't one, check your reputation or download limits, and show you the folder where this file and other files are located.

If you click on this link in the same browser on the same device a second time, the file will be downloaded instantly. This is true for both PCs and mobile devices.

If you close this window and click on the link from a private browser window, everything will repeat again, redirecting you to GoFile. At first, I thought it was some kind of bug and tried to work around it. But now I know that this is a feature of GoFile.

Amrayu78 I see from the logs that the GoFile API is not responding to our requests. The reason is unknown. I have already written to support and am waiting for a response.