Print

[Selroth]

It's been done!  We now own the Draconity.org domain name, as T-Sar has sold it to us.  After a bit of configuration and DNS updating, we can do a lot more with the domain name.

Webspace:
As mentioned on the shops thread, we can provide members individual webspace/homepages.  This includes PHP scripting, FTP access, and a high bandwidth cap and lots of storage space.  I'm looking for discussion on who should get this, who's interested, and what should the rules be.

Emails:
One major factor with us not owning the Draconity.org domain is we couldn't update the MX records.  Therefore, we couldn't fix the now working email issues, and we couldn't really create any new email accounts and expect them to work.  Now, we can.  So, again I ask who should get an @draconity.org address, who's interested, and the rules.

[Rocangus]

Well, when it comes to an address, I feel satisfied with @hotmail.com. Although... It could be something.

[J'Karrah]

Congratulations on purchasing the website!

[32-bit int]

Giving members individual webspaces seems like a good idea to me. However, some selectiveness would be an even better idea, as bad things can happen when servers run code written by incautious users. Perhaps a good system would be to allow any registered user to create a "dead", and relatively harmless, [X]HTML homepage, but only enable people who know what they're doing to upload any sort of server-side script?

Congratulations on purchasing the website!

I think he was talking about the domain name, rather than the web site.

[Rocangus]

I know nothing about coding and programing when it comes to these things. I have programed simple robots that just had their engines to be controlled. Thereby, you could make them go backwards, forwards, and turn left or right.

Although, I think I know that if you do a flaw in the programing of a site or something like that, it could overload the server. Is this correct?

[32-bit int]

Although, I think I know that if you do a flaw in the programing of a site or something like that, it could overload the server. Is this correct?

It depends on how the server is set up, what programming language the program is in etc., but under some circumstances it is possible for a bug in a web site's code to stuff up the whole server.

[Rocangus]

Like in EVE Online some time ago... There was a small code error in one string, and it caused the nodes to go on 100%. All the time. That's no good, is it?

[Selroth]

I'm far from concerned about the server or site security.  I think we're safe letting individuals have a small homepage or such - nothing too extreme.  If it takes up more bandwidth and space than the main site, then we may have issues :)

Webspace makes it easier for people to share files with eachother - you can upload it via FTP and provide friend(s) the URL.  This is much more effective compared to email attachments as well. 

If you're somewhat familiar with HTML, you can make a basic homepage and try out your skills.  Or you can figure out how to install PHP scripts, such as SMF which powers this website. 

Email can just be handy.  It's full POP account, and webmail access, and integrates with gmail nicely too.  SMTP as well (for sending emails).

[32-bit int]

FTP is a bit old hat nowadays. You can use HTTP to upload files instead. It's more efficient than FTP; HTTP is stateless, so there is less overhead. In an FTP transaction, the client has to notify the server it wants to communicate with FTP, wait for a reply, switch to a different port, and so on. With HTTP the client just sends a PUT or POST request with the required authentication details, and that's it. One way to do file uploading is with a web-based interface using asynchronous HTTP. I have used such a system, and it worked quite well. Using a web interface also makes it easy to embed tools other than an uploader. For example, the one I used (a free web hosting site called Ripway) had a built in text editor. However, implementation of HTTP's less well known features may be a bit more difficult than FTP, with FTP you can just install and configure any FTP server software, which should work with any FTP client, but most HTTP servers are designed for read-only page serving. I once wrote an HTTP server which could easily be adapted to receive and process uploads, but it hasn't been extensively tested.

I'm not too keen on email. Email authentication is kinda difficult; you can rarely be sure an email came from where it says it came from. And of course, there's spam. spam. spam. spam... I only use email when I have to.

[Rocangus]

Spam... That's something that's plaguing me. I come home from, say school, check my mail, and then there's a mail in the junk folder, with some offer on something. I just mark it as read and throw it away. Annoying anyway.

[NearToTheSky]

You want to be extremely careful letting people post HTML pages under your own domain, because that can expose you to XSS and such nasty things.
For exemple, most browsers will protect cookies so that one domain can only see cookies that were sent by itself, but will let everything from one domain happily read all cookies sent by the domain indiscriminately. If you let soomeone do a simple html page under the draconity.org domain, they may add a javascript to it that will gather your authentication cookies and send them somewhere... Then they encourage you to visit it and poof, they get access to your admin session and can do everything using your credentials (I can search for proof of concept code for you, if you wish).
Also, if you want to go with it anyway, make sure that people have credentials for uploading that they can only use over ftps, sftp or https (basically, make sure they're always encrypted). You don't want such credentials to go out in cleartext on the network.

Regarding php, it isn't much of an issue, but you should be aware that php has a number of "dangerous" functions that can be used to compromisse the server or other sites running on it. Be sure to check what extensions you are using and disable any function that is dangerous in the php.ini file (and generally, check for any weakness there). Look around on the web for what php functionality are considered dangerous, there are many misleading things about php.

Regarding mail, if you already have a mail server running and that it seems to be working fine for incoming mail, adding email addresses shouldn't expose you to trouble. You don't open the service for sending mails -  no one needs that and it's making you risk to get your server used by spammers. If you set up a webmail service, it would of course be an exception - just make sure it's secure.

[Rocangus]

Security is the key I guess. When it comes to tech stuff this deep, I'm lost.

[32-bit int]

You want to be extremely careful letting people post HTML pages under your own domain, because that can expose you to XSS and such nasty things.

That's why I suggested only allowing dead HTML.

For exemple, most browsers will protect cookies so that one domain can only see cookies that were sent by itself, but will let everything from one domain happily read all cookies sent by the domain indiscriminately. If you let soomeone do a simple html page under the draconity.org domain, they may add a javascript to it that will gather your authentication cookies and send them somewhere... Then they encourage you to visit it and poof, they get access to your admin session and can do everything using your credentials (I can search for proof of concept code for you, if you wish).

I hadn't thought of Javascript... but surely that sort of exploit could be prevented by validating every uploaded page against a modified version of the appropriate HTML/XHTML DTD, with the <script> element type declaration removed. Doing so should ensure that the uploaded markup is script free and standards-compliant (or at least, partially standards compliant) all at once.

Oh, and if anyone needs an example XSS exploit... actually, forget I said that.

[Selroth]

It seems that people are more concerned about the security and no one has really expressed any desire for any of these extras.  So, I think the answer is simple then: Not to offer it :)

[Rocangus]

Aww, that's a shame... I looked forward to them.

[Tags:]

Tags: