Daddy

Still an issue

I am, but our API is public (using your rest API integration) and that endpoint exposes the full path. So we can't give the endpoint out to regular users to download paid content because it would expose the path. That's why we've opted to move uploaded content to a non-public to avoid this, but now there doesn't seem like a way to download files remotely now.

I'm looking at the /api/downloads/files/{id}/download endpoint and I'm not seeing an actual viable way to download the file. I can either store the file in a public directory and expose its full path for anyone to share (without purchasing) or just have no way of downloading through API? Currently, I store all uploaded files in a non-public directory, so even if the full path is exposed, you can't access it (as it should be.) Since the response gives you the actual path, instead of a proxy URL, you can't actually use the URL response to download the file (because it's not public.) Is this intentional? Doesn't seem right.

Is it possible to have the option to replace existing code instead of injecting before or after? Right now it doesn't seem possible to remove and move things around. Right now it doesn't seem possible to have a truly custom theme.

I'm not fully understanding the new theme editor. How do I modify the entire page without having to inject my code with pre-defined placements? My design is completely custom. I do not like IPS design personally. Am I missing where to access the raw template code?

I'm not trying to beat anyone up over this, but I don't see how the coming and going of those with admin access is relevant to security. Not everyone with ACP access has full access. We utilize the in-depth permission system to give team members certain scopes to work with. But even with a small team that rarely changes, their IP will change quite often, which means using a firewall to block access will be impossible without some type of custom integration. 2FA does solve the problem, but I (and I'm sure others) would prefer not to have the page accessible to anyone. Given IPS is a well-known software, the default location is easily accessible and is a very common path that many other CMS's use. It would make me feel better being able to set a unique name so people can't stumble upon it, even if it's secure. Was there any particular reason this feature had to go? I agree it didn't make much sense in regards to security, but it didn't hurt? I feel like the usefulness of this was underestimated when this was decided upon. The lack of a deprecation warning until now seems a bit odd as well. Surely this is going to be overlooked up until IPS5.

I mistook the default for admincp instead of just admin. My mistake on that one. But regardless of the point, security through obscurity is a fantastic layer of security and one that should not be removed. Sure, you can block the page in your firewall or Cloudflare rules, but there's no easy way to make this dynamic. Anytime you add or remove a user with ACP access, you now have to whitelist their IP, many of which are dynamic and change every other day. It’s simple enough to keep and is especially useful for adding an extra layer of security to your suite. If you truly think obscurity isn’t a secure measure, let me introduce you to steganography! (Directed at Jim)

If this is the case, why did Invision change their admincp location from default?

Need to know what changed in forums -> front -> index -> forumRow as it's not listed in theme differences

Upload a new version of a file. It doesn't matter if you add more screenshots or not. Go into changelog and select the previous version. Click restore. Now clear your cache and all of the images will be broken. You can verify this by clicking update and scrolling to the screenshot section to see they're all 0mb.

When you restore a previous version, not only are the screenshots deleted from the version that got reverted, but all screenshots are deleted. While they may appear to still be there the file manager shows them at 0mb and when your cache expires it shows a broken image for every single screenshot uploaded, regardless what version it was added in.

As the title states, Stripe has CashApp Pay integration, but IPS integration is falling behind. Would be great to have this added. While you're at it, WeChat and Link are also missing.

Yeah I don't see developers sticking together on a single marketplace. We'll end up with at least a dozen off the jump so be mindful where you buy.

Here's mine for reference: (not http.cookie contains "ips4_member_id" and not http.request.uri contains "login" and not http.request.uri contains "register" and not http.request.uri contains "app" and not http.request.uri contains "contact" and not http.cookie contains "ips4_IPSSessionAdmin" and not http.request.uri contains "terms")

Alright, so I cleared cache + redis cache + cloudflare cache, and it seems to be working now on Edge and Chrome. I haven't tested Firefox.

Any traction on this? Not having guest caching is a huge problem.

I dug a bit deeper, and it seems the issue is users being able to type in an incorrect name while gifting a file. If the user does not exist, this error occurs where the invoice does not get marked paid. Trying to mark it manually paid produces the above error.

The invoice was never marked paid, despite payment being accepted. The mark paid is me trying to mark it paid in the ACP but it errors out.

Needs update: BadMethodCallException: (0) #0 /home/-----/public_html/applications/nexus/sources/Invoice/Invoice.php(2016): IPS\nexus\_Purchase->__call('onPurchaseGener...', Array) #1 /home/-----/public_html/init.php(932) : eval()'d code(23): IPS\nexus\_Invoice->markPaid(Object(IPS\Member)) #2 /home/-----/public_html/applications/nexus/modules/admin/payments/invoices.php(284): IPS\nexus\hook2653->markPaid(Object(IPS\Member)) #3 /home/-----/public_html/system/Dispatcher/Controller.php(107): IPS\nexus\modules\admin\payments\_invoices->paid() #4 /home/-----/public_html/applications/nexus/modules/admin/payments/invoices.php(40): IPS\Dispatcher\_Controller->execute() #5 /home/-----/public_html/system/Dispatcher/Dispatcher.php(153): IPS\nexus\modules\admin\payments\_invoices->execute() #6 /home/-----/public_html/cfapp/index.php(13): IPS\_Dispatcher->run() #7 {main}

I'll be honest when I saw this thread, I almost went for the popcorn, but this is actually a pretty big W for self-hosted licenses. Removing the ability to select apps is actually smart. While it may greatly restrict your ability to budget on smaller orgs, it kind of pushes you into trying them and finding ways to monetize. Both of my licenses were missing apps, so having access to them all while still paying less kind of blows my mind. This was not on my "what will IPS do next" bingo card. A step in the right direction and much appreciated by us self-hosted customers!

Thank you!

Attempting to purchase a file feature using: https://invisioncommunity.com/files/file/9038-feature-my-file/ I tried following the error but hit a dead end. Not sure if it's related to the plugin or not. I submitted a support request on the support page for feature my file but it's been 5 days and still not approved

Error: Access to undeclared static property IPS\nexus\extensions\nexus\Item\MiscellaneousCharge::$nitialInterval (0) #0 /home/----/public_html/applications/nexus/modules/front/checkout/checkout.php(1249): IPS\nexus\Invoice\_Item->__get('nitialInterval') #1 /home/----/public_html/init.php(932) : eval()'d code(749): IPS\nexus\modules\front\checkout\_checkout->_pay(Array) #2 /home/----/public_html/system/Helpers/Wizard/Wizard.php(181): IPS\nexus\modules\front\checkout\xxxxx->_pay(Array) #3 /home/----/public_html/applications/nexus/modules/front/checkout/checkout.php(170): IPS\Helpers\_Wizard->__toString() #4 /home/----/public_html/system/Dispatcher/Controller.php(118): IPS\nexus\modules\front\checkout\_checkout->manage() #5 /home/----/public_html/applications/nexus/modules/front/checkout/checkout.php(57): IPS\Dispatcher\_Controller->execute() #6 /home/----/public_html/system/Dispatcher/Dispatcher.php(153): IPS\nexus\modules\front\checkout\_checkout->execute() #7 /home/----/public_html/index.php(13): IPS\_Dispatcher->run() #8 {main}

I'm opening up our OAuth to securely authenticate users and download files remotely from the site. In doing so, we have to store their OAuth access token locally. The problem is with the /downloads/files/{id}/download scope exposing the FQDN of the file itself. That's a bit of an issue since the FQND of the file never changes and anyone with the URL can download, regardless if they have access to it or not. The issue we're facing is the fact the user can get ahold of their token if they tried hard enough. That means they can run their own API call to fetch the FQND of any file they have access to. That's a bit dangerous. Sure it's no different than them just leaking the file itself, but at least we have logs of their download and can track it. Downloading the file with the FQND isn't logged. Any suggestions? PS: In our application, all of the API calls are made via our webserver using web requests instead of direct calls. The hope there is to help prevent users from attempting to recreate the same calls with their token. Problem is, the API for Rest is public on IPS so the user can easily recreate them anyways.