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