Private Little Idea C# Flash/Shockwave Client

[ovflowd]

Hi folks, how are everyone?
Thinking a little i had a little idea (recommended by @Glaceon).
Why don't wrap a Client in C#?

What i mean with this?
The CMS still remains in your Browser, but when you click in Enter in Habbo Hotel (Enter in Client) will give a URI like: habbo://username:USERNAME;token:CLIENT-TOKEN

That means that the Token will be created directly in the Me.php (something like that) (code will be provided)

This protocol handler will call the C# Client that you installed in your PC. This Client will contain the same HTML of a Client.php + the Habbo Client Javascripts + Flash + Schockware Handler Support.

The Client will be open source and in the Source Code will be a Settings Section where you configure:
1. Server Port
2. Server IP
3. It's Proxy?
4. URI for Hotel
5. Base URI for Client
6. GameData folder
7. Where is External Texts, Variables, Productdata, etc.etc.
8. GORDON Folder
9. It's Flash or Shockware

Will be custom settings for Flash or Shockwave.
Also Hotel Name and Intro Text and Favicon Location

When you build it, will generate a .exe that by default will be called Client.exe
Will be like a browser but only with options: Close Client, Enter Fullscreen and the Close/Minimize Windows Toolbar Options.

Also will be provided a Installer Script for some Generic Installer Creator where you select the Client.exe images for the Installer and Title. And also the Installer will create the Protocol Handler.

Resuming: Will be a Client that work Flash and Shockwave. So you don't need to do tricks or something else to enable Shockwave or Flash when be disabled.

Yeah, you will need download an Installer, that's not cool, since Habbo idea it's just enter client. But i think 90% people would install it since it's really easy and will be like 1mb on max.

Also the ability of put ADS. And maybe a way to communicate that the User is VIP. Something like that.

What your guys thing about it?

 

[Emily]

No need for Javascript for the client. Also:

The Client will be open source and in the Source Code will be a Settings Section where you configure:

We got configuration files for this.

 

[Moogly]

I should point out: This isn't creating a client, but wrapping one. Please don't say create, we don't need the next 5 years of kids thinking they created a Habbo client, when they're just wrapping it. I've thought about something similar, but anytime you make someone download something to go on a retro you get a LOT of friction, and too much trouble, now you have other retros making kids download malware in the mix. Too many issues.

 

[ovflowd]

No need for Javascript for the client. Also:



We got configuration files for this.

Yes but if we use that... Users can edit it..

I should point out: This isn't creating a client, but wrapping one. Please don't say create, we don't need the next 5 years of kids thinking they created a Habbo client, when they're just wrapping it. I've thought about something similar, but anytime you make someone download something to go on a retro you get a LOT of friction, and too much trouble, now you have other retros making kids download malware in the mix. Too many issues.

Ok, renaming to Wrapping it hahah. Wrecking Ralph <3

 

[maritnmine]

when you click in Enter in Habbo Hotel (Enter in Client) will give a URI like: habbo://username:USERNAME;token:CLIENT-TOKEN

[STRIKE]
Why not use something like OAuth instead? You are making this sound really complicated. [/STRIKE]


Other than that, I really don't see any benefit or point at all of wrapping the client in an .exe. When doing this you limit your userbase from any platform that supports a browser running Flash/Shockwave to Windows where the users does also have to have the targeted .NET Framework installed for the client. However, you might get around this if you use something like Xamarin.

I was thinking about this myself many years ago, but decided not to go with it since for most people it does not give much value separating the client from the cms and there is additional cost maintaining/developing the client. On the other hand, its very good for people with low bandwidth as it may reduce the bandwidth usage where the entire client and all the gamefiles are downloaded at once.

But I still fail to see why you would do something like this, as it really just makes things more complicated.

Edit:
Nvm first part I misunderstood your broken Google Translate English.

 

[Emily]

@maritnmine it doesn't take very long to create the client. One of the biggest issues would be how to make it stable, quick and efficient. Maybe I can explain it better with an example. For example, my project is a v38 server for both shockwave and flash. It uses SSO ticket blabla. When the user is on the website, there has to be a way to open the .exe and for example the flash client or shockwave client. It also needs to generate a new SSO ticket and "send" it to the client (or generate it on the client of course). But then again, there should also be website clients so you don't need to download an external .exe. But if you update something in the website clients, the external clients need to have the same updates. Also, I don't know if it's possible to use COM .dll's in either Java or C++, as both work for all platforms, the only thing the user needs is the .dll for shockwave, right? I don't know if I'm seeing it the right way but this is what I was thinking.

 

[ovflowd]

[STRIKE]
Why not use something like OAuth instead? You are making this sound really complicated. [/STRIKE]


Other than that, I really don't see any benefit or point at all of wrapping the client in an .exe. When doing this you limit your userbase from any platform that supports a browser running Flash/Shockwave to Windows where the users does also have to have the targeted .NET Framework installed for the client. However, you might get around this if you use something like Xamarin.

I was thinking about this myself many years ago, but decided not to go with it since for most people it does not give much value separating the client from the cms and there is additional cost maintaining/developing the client. On the other hand, its very good for people with low bandwidth as it may reduce the bandwidth usage where the entire client and all the gamefiles are downloaded at once.

But I still fail to see why you would do something like this, as it really just makes things more complicated.

Edit:
Nvm first part I misunderstood your broken Google Translate English.

Agree with you.

So some points:
1. OAuth people need configure it. Since every emulator uses MySQL i can simply do a communication between Emulator? But better not, security issue.
2. OAuth will be something complex for something so simple.
3. I can do it in Java, multiplaform ok.

Answering Glaceon points
1. A simple solution is we offer the modification in the uri of me.php habbo://hotel-id:MyHABBO.com;token:GeneratedTokenInMe
The client will be unique for any hotel. Those params will inform the Token and the HTTP Base URL of the Hotel.
2. The solution will contain client-auth.php that will receive a MyHABBO.com/client-auth.php?token=GeneratedTokenInMe
3. The solution will answer a jSON with the Hotel Client Settings and User Details.

I can give here a preview of the code:

ClientAuth.php

<?php

class Client
{
   #database stuff
   # SSO stuff
   # jSON stuff
   # request stuff
}

Client::prepare(); // Prepare Database & Stuff
Client::doRequest(); // Check for $_GET... etc and give response, if $_GET['token'] and if HTTP Requested URI is /ClientAuth if $_GET doesn't exists or Request URI isn't... so .. cancel..

Me.php (Top of the File)

<?php [USER=2000143283]require[/USER] 'ClientAuth.php';

$token = Client::generateToken($_SESSION['id']);

?>

<a href="habbo://{uri: 'http://myhabbo.com'; token: '<?= $token ?>'}">Enter Habbo</a>

jSON example

{
  user : {
   id: 7,
   name: "Claudio"
  }
  server : {
   ip: "172.0.0.1",
   port: 30000,
   http: "http://myhabbo.com/me",
   logout "http://myhabbo.com/logout",
   base: "http://myhabbo.com/swf/",
   gordon: "http://myhabbo.com/swf/gordon/RELEASE..../",
   gamedata: "http://myhabbo.com/swf/gamedata",
   variables...
   ...
   name: "My Habbo",
   enter: "Loading My Habbo...."
  }
}

So the Client in Java will communicate with the server provided in the habbo:// protocol.
So we don't have anymore upgrades problem.

And also an own api for the HOTEL.

The CLientAuth only will answer the user data (jSON) if the Token it's valid. If is, the ClientAuth automatically will generate a new random token and store it on database (and will NOT inform to the Client)... The token will generated only after the Client answers that Entered in Game Successfully. or something like that. (Optional)

because the same token can be reused if someone intercept the communication between Client & ClientAuth.
Or a secondary way it's the token provided by the habbo:// wrapper it's a Primary Token, and the ClientAuth answer a second Token to the User Login. So if the User uses this recently generated Token by the ClientAuth, the same process happens again. Dunno. Maybe someone can give a better tip.

 

[maritnmine]

One of the biggest issues would be how to make it stable, quick and efficient.

Why is making it stable and quick a big issue? You just embed the client in a browser view, many apps already do that today (Slack, Discord, Spotify, ...)
saamus thnx for the jSON examples!

 

[Emily]

@maritnmine I didn't really mean that, I don't even know why I posted that. I more meant the rest of my message.

 

[ovflowd]

@maritnmine I didn't really mean that, I don't even know why I posted that. I more meant the rest of my message.

Glaceon i think you're to much time in the Ice land with Glaceon. (lolwut & lelwut)

Can someone answer if my idea it's good?
maritnmine can you suggest something about security?

#ontopic
I think this one i can create and in Java + PhhhhhppPphp <3

Thanks marit, i think the jSON example illustrates how this thing can be.



And, yeah maritnmine, i broke the Google Translator.. Kidding, i don't use it.


Glaceon can you tell me where you found the Flash + Shockwave API for Java or C#?



Found that: http://fobs.sourceforge.net, it's useful?



Found this also: http://www.ezjcom.com/onlinedocs/java2com/Basics.html

 

[Emily]

@saamus No, you need no API. You only need the .dll. Then you have to add the dll as a toolbox item to your project, then you can use the control in your Winforms project. But it's kind of buggy, like you can't drag it to move it or click on it and see its properties.

 

[ovflowd]

@saamus No, you need no API. You only need the .dll. Then you have to add the dll as a toolbox item to your project, then you can use the control in your Winforms project. But it's kind of buggy, like you can't drag it to move it or click on it and see its properties.

What you mean with the DLL? I'm saying that the Hotel Settings will be sent by the HTTP Request. And the Server URI will be specified in the habbo:// URI. Martin liked that. And its good. I don't need any configuration in any .ini files or in anything. The Java or C# Client will be totally Universal. For any hotel.

You mean the DLL from Flash? and Shockwave? Where i get those? I didn't found in the web.

 

[Emily]

What you mean with the DLL? I'm saying that the Hotel Settings will be sent by the HTTP Request. And the Server URI will be specified in the habbo:// URI. Martin liked that. And its good. I don't need any configuration in any .ini files or in anything. The Java or C# Client will be totally Universal. For any hotel.

You mean the DLL from Flash? and Shockwave? Where i get those? I didn't found in the web.

You get the DLL from shockwave from installing shockwave, and as for flash, I assume it's the same. And I meant DLL to display the client in Windows Forms as I thought you meant that.

 

[ovflowd]

You get the DLL from shockwave from installing shockwave, and as for flash, I assume it's the same. And I meant DLL to display the client in Windows Forms as I thought you meant that.

Yes this i understood. I will do a research about it. Thanks.

 

[maritnmine]

And I meant DLL to display the client in Windows Forms as I thought you meant that.

Don't do that. marit does not like this.

 

[Emily]

Don't do that. marit does not like this.

But, maybe mine likes it? But anyways, I'd love to know why you say that. I want to learn stuff so an explanation please.

 

[ovflowd]

But, maybe mine likes it? But anyways, I'd love to know why you say that. I want to learn stuff so an explanation please.

I will like an explanation also. Haha, i'm soo newbie on this..

 

[maritnmine]

I'm not gonna write a 5 page ELI5 on why you shouldn't do this in winforms since I simply don't have the time. Winforms is a very old technology which had the focus on allowing developers to easily put together UIs that would work on some business logic. As time moved on, better alternatives came up (such as WPF) and people moved for the most part to the web. Winforms had proven to be very hard to test, it was very little modulateable and you had a very poor separation of concerns in the application. Microsoft is no longer adding new features to winforms and is only maintaining it.

In context of Habbo, it is even worse as it limits your userbase to only users running Windows on the targeted .NET Framework of the client. Go with something else, there are better alternatives. Its 2016, jesus christ.

 

[Jamal7]

I'm not gonna write a 5 page ELI5 on why you shouldn't do this in winforms since I simply don't have the time. Winforms is a very old technology which had the focus on allowing developers to easily put together UIs that would work on some business logic. As time moved on, better alternatives came up (such as WPF) and people moved for the most part to the web. Winforms had proven to be very hard to test, it was very little modulateable and you had a very poor separation of concerns in the application. Microsoft is no longer adding new features to winforms and is only maintaining it.

In context of Habbo, it is even worse as it limits your userbase to only users running Windows on the targeted .NET Framework of the client. Go with something else, there are better alternatives. Its 2016, jesus christ.

Windows 8 (all editions) includes the .NET Framework 4.5 as an OS component, and it is installed by default.
Windows 8.1 (all editions) includes the .NET Framework 4.5.1 as an OS component, and it is installed by default.

Windows 10 (all editions) includes the .NET Framework 4.6 as an OS component, and it is installed by default.

Its 2016, jesus christ. Who uses old Windows versions

 

[maritnmine]

[list of windows versions and .net framework]
Its 2016, jesus christ. Who uses old Windows versions

Don't think you get my point. Main problem is that they want to use some very ancient technology nobody creates new things with any more that is only limited to Windows.