I do belive what @EchoReaper is saying is right, most admin scripts has a server script, or a module put in SSS
Can we please make 3rd party sales allowed by default? Where are the systemic issues happening that make it necessary to disallow 3rd party sales for everyone except a select few? Sure, some rogue admin script maker like khols could create a dumb update that spams everyone with purchase requests, but if it does then people take notice and then no longer use it.
Most basic ones are serverside only.
Those that are a tiny bit more advanced also use localscripts, but are still based on the server.
I only know of a few admins that are only locally, but those can’t be really counted.
(They almost never get used in real games, nor would they work with FilteringEnabled)
It would be best if you could edit the whitelist serverside, since the server is safe anyway.
(I mean, if an exploiter can execute code serverside, you’ve already lost the battle)
1 Like
Solution: call PromptPurchase (we don’t even have to worry about PromptProductPurchase since it is already per-game) from the client and store shop values in a localscript.
Significantly less delay between pressing a button and the purchase CoreGui coming up, and we don’t have to worry about this exploit.
Or just don’t store important values where they can be changed & replicated. Bonus points for non-FE games: store the shopgui in ServerStorage and have a script in SeverScriptService manually copy it into playergui on respawn.
As for virus scripts, these haven’t been a serious threat in popular games for years. And no virus script on the market is sophisticated enough to modify shop values like this. Even if one like this was created, it would be the creator’s fault for inserting it and not properly playing and testing their own game and noticing this.
In this end,
is not true. This is a feature that promotes poor and insecure shop design. FE or not, it is completely possible to make a shop that cannot be exploited.
On another note, it may be important to add that the more advanced admin scripts which utilize both local and server-side scripts are 99% of the admin scripts in games that have non-custom admin.
3 Likes
@berezaa is mostly right, without this feature secure shops are definitly possible.
The only ways an exploiter could replace assetIds are:
- The assetIds are stored in IntValues which the exploiter changes
- I actually thought I could come up with more ideas…
First of all, with FE, those aren’t a problem.
Second thing: Any shop that uses that is ancient and bad.
It’s like having a game where everyone can use all the admin commands.
You can’t really do something about it if the creator is being very insecure.
Yes, exploiters could still locally change the assetIds, but what bad does that do?
They’ll pay the price (literally) and won’t gain any advantages in the game.
(Unless you get stuff if you buy ANYTHING, which is, again, very bad design)
I even like people doing that in my game: I still get a 10% commission on their purchases.
So let them try to exploit and waste money, I’ll even get paid for their poor tries.
1 Like
I didn’t get a reply on my post @ConvexHero
Will this be a problem for me, or is there any way that a puchase isn’t stopped by this box that is dissabled in workspace.
Problems caused if there’s no way around this box.
The user has to enable third party to be able to first unlock the admin.
Then the users can’t donate, because they have to enable third party first.
The other users who joins the game can’t take the admin unless the owner of the game enables third party.
And proabebly more, but can’t come up with more right now.
Now to questions.
Is there any other purchase way that isn’t affected by this, were i can sell acess to my admin without the owner to enable things that is dissabled by default?
Is there any ways users can donate without the owner having to enable this feature?
1 Like
Actually, this isn’t entirely correct. You could remove all of the buttons from their shop and replace them with identical ones hooked up to your own events that sell your assets. This can’t be used on a large scale because it requires you to manually discern their GUI structure, but you can do it on a small scale with games in top earning and make a lot of money.
You can’t do that using localscripts, you need to be able to run serverside code for that.
(Or worse, the ability to run localscripts on other clients)
1 Like
The guy that switched out all of the items in the shop on front page games didn’t seem to have a problem with that
1 Like
What?
Shouldn’t be possible unless you allow people to run serverside code in some way…
1 Like
[quote=“ConvexHero, post:31, topic:19814”]
The original issue was an exploiter who replace the asset id’s for a popular, non-fe, game’s shop.
[/quote]
1 Like
[quote=“EchoReaper, post:52, topic:19814, full:true”]
Probably by changing IntValues
If this is the case then there is no reason for a feature that causes more problems than it solves.
So wait a minute, why isn’t this just under the MarketplaceService?
I understand that it isn’t visible in the explorer by default, but that can be changed.
It doesn’t make much sense for this property to be under a storage class for world geometry, rather than a service meant for transactions.
2 Likes
Well, with FilteringEnabled already being there, it’s not like we’re breaking a big organised system.
True, though FilteringEnabled at least makes some sense there because its effects are generally noticed in the Workspace.
3 Likes
When is the client finally get updated to make this work?
Or does this have to be set from studio instead of a (normal) script online?
(It’s settable by a script, so I would assume the latter would work)
Did anyone actually even notice if third models are allowed when this is set to true?
1 Like
As long as I can query this then I am okay with it. I often add a little donate button for myself in my models if they took me a large amount of time. I don’t want to miss out on that.
1 Like
I just tested: The client still doesn’t react differently to AllowThirdPartySales being true.
2 Likes