It can be any ClickID as long as it's tracked on a per use basis. Named buttons offer a better solution as the name is the key, and the ClickID for each user could be stored as it's value. So when you want to send the same button all users, label it. Within the button handler, it will find the next available ClickID for each client and return it back to the system. This is then saved in an array that will have the buttons label as a first level key. After that, it will cantain an array that will have the Key as the UCID, and the ClickID as it's value. That would look like this ...
<?php
$this->buttonsToAll = array($ButtonLabel => array($UCID => $ClickID);
?>
I'll go with that within the context of the OAuth data, but I would still like to know their license level for other reasons within the game. Not that it's a huge issue when it comes to license levels, but it's nice to know. Whereas DEMO vs Licensed is a must know in some cases.
LFS, OAuth & PRISM.
So, I was talking to T3 the other day on his server about how to secure parts of PRISM. I've come to the conclusion that this can be done correctly only for the web site front end and in game, where a chain or trust already exists. Anything that happens within PRISM regarding passwords can't be considered safe if you don't trust the host that is running PRISM. PRISM is the man in the middle in this case, and that's the nature of the beast. So the only solution is to remove the man in the middle from handling any senstive information that it can't be trusted with. There are 3 aspects where this becomes important.
Regarding demo users vs that of S1 and S2.
There is another argument to be made about the level of trust extended to a DEMO user vs that of a S1 or S2 user. Where a user has unlocked his client to a S1 or S2 level is a authenticated user that can be tracked and handled. Demo users on the other hand don't have this level of trust extended to them as the client's status has no weight or value. The information could be used once and thrown away by each demo user as their accounts are banned from servers.
- In Game.
In game, the client is already authenticated by the LFS master servers. This is not the case with demo races, but a level of trust can be assumed. On S1 and S2 servers the level can be asserted to a slightly greater level as user name and password is required to connect to a S1 or S2 server with the game client. (Ie, the game has to be unlocked with the client's password.) This can not be absolute as there may be a situation where the LFS client can be compromised, and that would also compromise the integrity of PRISM. But really, if the game trusts them, we should trust them too.
- On PRISM's Web Front End.
There is where OAuth comes in. Whereas LFSWorld / LFS.net set it's self up as a OAuth provider. When some one tries to login to the web site front end, they are asked to login using their LFS credentials, but as the username and password is entered on LFS's servers and not PRISM's we can again trust that as long as LFS says that it's ok, then it should be ok for us as well.
- On PRISM's Telnet Client.
This one is the hard one. The telnet client is handled on PRISMs end. We can't use a LFS password for this case as the server operator might change the nature of how PRISM works and instead of sending your password to LFSWorld, it might do that, but also save it plain text in a file some where. This is not an acceptable security risk, so users within say the website front end, or the game would have to setup a password from there. So the chain of trust only extends to the PRISM server host, but it leaves the security of the LFS information intact as it would not use those credentials.
Regarding demo users vs that of S1 and S2.
There is another argument to be made about the level of trust extended to a DEMO user vs that of a S1 or S2 user. Where a user has unlocked his client to a S1 or S2 level is a authenticated user that can be tracked and handled. Demo users on the other hand don't have this level of trust extended to them as the client's status has no weight or value. The information could be used once and thrown away by each demo user as their accounts are banned from servers.
Last edited by Dygear, .
Much thanks to the community around me. This update was really put up together by GeForz, I just made it work within the current system. We have a long way to go, Version 0.4.0, vs Version 1.0.0 ...
It does also help that I'm out of Medic school, and that I've passed all of my exams.
But while some of this is still not over. I have 4 days, where I am to be cleared as a Paramedic at my job, because it's a title upgrade I have to go through some on site training on the Vent and IABP and things like that. So while I'm doing that I hope that you all give the 0.4.0 branch a really good run down on what works well, what does not and what needs to be changed, and what should say the same.
I realized that I did that packet system wrong from a fundamental point of view. Button packets are going to have to sent to the button class, and bypass the plugin system altogether for this to function efficiently. Although, it's not going to look pretty in the core the first time I implement it. I do expect that some other pass-throughs it will get better. That said, I would also refactor some of your code T3, you did a good job, but I have some other more concise ideas for this, although your theory is correct.
Last edited by Dygear, .
Sweet! I might just do that!
This is something that I am really hoping to nail before 0.5.0 of PRISM. But I could use some help!
Is it currently not recommended that anyone use this version that's not very brave. This is not a stable release, but there have been many improvements that GeForz has added in the way of the button interface. This is a experimental test version (as really they all are, but this one more so), and should be used at your own risk only.
Good luck, and good hunting!
Good luck, and good hunting!
PHPInSimMod - PRISM 0.4.0 Discussion
You can download PHPInSimMod - PRISM 0.4.0 from that link. Please use this thread to talk about this release.
Thank you.
PHPInSimMod (PRISM) 0.4.0
Thank you.
PHPInSimMod (PRISM) 0.4.0
- Added a Button handler, that should be used to ensure no button colisions occur.
- Includes Button class, to be used in place of IS_BTN directly.
- Includes Singlton Button Manager.
- Added an implementable callback called 'onButtonRequest' for plugins.
- Includes Button class, to be used in place of IS_BTN directly.
- Changed around the registerSayCommand's callback functions order of args, was done in a pervious version but never documented. Beware!
- Added packet Size default value to IS_CON.
- Added object list to the prism_layoutobject thanks to T3charmy.
- Can now also send IS_AXM packets. But be careful as the Info limit of 30 not enforced at the packet level, it must be done so within the plugin.
- Fixed sent size in IS_HLV & IS_OBH to the CarContOBJ parser.
- Fixed Undefined variable: command in canUserAccessCommand
- Fixed IS_ACR's UNPACK definition, now reads correctly.
- Fixed UNPACK definition of IS_AXM, packet now works as expected when reciving.
- Fixed crash when IS_OBH is sent due to CarContOBJ->Sp3 being set to protected, change to private.
- Fixed Undefined variable in prism_plugins (line 252).
- Fixed IS_PLC's PACK and UNPACK (Thanks Krammeh).
PHPInSimMod (PRISM) 0.4.0
PHPInSimMod (PRISM) 0.4.0
- Added a Button handler, that should be used to ensure no button colisions occur.
- Includes Button class, to be used in place of IS_BTN directly.
- Includes Singlton Button Manager.
- Added an implementable callback called 'onButtonRequest' for plugins.
- Includes Button class, to be used in place of IS_BTN directly.
- Changed around the registerSayCommand's callback functions order of args, was done in a pervious version but never documented. Beware!
- Added packet Size default value to IS_CON.
- Added object list to the prism_layoutobject thanks to T3charmy.
- Can now also send IS_AXM packets. But be careful as the Info limit of 30 not enforced at the packet level, it must be done so within the plugin.
- Fixed sent size in IS_HLV & IS_OBH to the CarContOBJ parser.
- Fixed Undefined variable: command in canUserAccessCommand
- Fixed IS_ACR's UNPACK definition, now reads correctly.
- Fixed UNPACK definition of IS_AXM, packet now works as expected when reciving.
- Fixed crash when IS_OBH is sent due to CarContOBJ->Sp3 being set to protected, change to private.
- Fixed Undefined variable in prism_plugins (line 252).
- Fixed IS_PLC's PACK and UNPACK (Thanks Krammeh).
Spec them, as it's the same as a jump start, and that's how LFS handles it on their grid so it's better to keep consistent.
Using UTF-8 strings natively would of killed Scawen?
No, I'm not home to submit the fix. I'm sitting in my ambulance corps right now.
It was the only packet that I did not check. 
Sorry all.
Sorry all.
.Lol, yeah it was filur. I wonder if I have the source code. I'll see if I can't change it around to use AXM & objects.
I've been on the server, and it works really well. Very impressed with what has been done.
I might of changed around the $UCID and $Cmd commands. Sorry if this was not in the change log, I must of forgot that I did it.
Thank you for the fix, I'll include it in the next patch.
The difference was intent. Schumacher knew that Rubens was there, and forced him to the wall. Button did not see Lewis and this was the result. They are similar, but not the same.
Vetal is human, Button wins! You are forgiven button for today!
I'll pull it when I get home, nice work and fix the errors mentioned.
So no one want's to go over to 0.6A1? That's odd, usually people scramble to get the new patch.
Your right that should be 8, 8, although it does not cause a bug, so I'll fix it in the next version.
FGED GREDG RDFGDR GSFDG