OpenEx: Progress Report - 95% launching this week

[oncebitcoinedtwiceshy]

Stablecoin may in fact find a home on the exchange, since we are having problems with Gridcoin and there are varying reports on whether the coin actually works as intended or not.

Thanks for the feedback, we'll keep our fingers crossed and await the verdict!

[1715031019]

1715031019

[1715031019]

1715031019

[1715031019]

1715031019

[1715031019]

1715031019

[1715031019]

1715031019

[mr_random]

that sounds great r3wt, but what about forged ip address in http headers? great question.
functiong getIP()--this makes it difficult to cloak or forge the ip address.

Code:

<?php
function getIP()
{
    foreach (array(
        'HTTP_CLIENT_IP',
        'HTTP_X_FORWARDED_FOR',
        'HTTP_X_FORWARDED',
        'HTTP_X_CLUSTER_CLIENT_IP',
        'HTTP_FORWARDED_FOR',
        'HTTP_FORWARDED',
        'REMOTE_ADDR'
    ) as $key) {
        if (array_key_exists($key, $_SERVER) === true) {
            foreach (array_map('trim', explode(',', $_SERVER[$key])) as $ip) {
                if (filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE) !== false) {
                    return $ip;
                }
            }
        }
    }
}
?>

Works IF a user does not use a Proxy that does not send HTTP_X_FORWARD Headers or a VPN.

I could not post this here at the time (newbie)but please read this:

https://bitcointalk.org/index.php?topic=374922.0

You're really splitting hairs picking at that bit of code. I agree however that not using transactions is shocking. How did OP get so far into the project and not know what transactions are?

[monsterer]

The code posted so far here scares me. Why are you not using mysql prepared statements? You're just asking to be injection attacked.

[r3wt]

The code posted so far here scares me. Why are you not using mysql prepared statements? You're just asking to be injection attacked.

i don't know how to use them. i tried, but it makes getting results harder. i have < 6 months experience. maybe one of you really smart guys would like to join the staff in a paid position as dev # 3? if not, maybe you would like to be paid nicely to convert all our queries to PDO? I'm willing to accept that i don't know everything there is to know, and that one of you take our work and make it alot better. any takers?

[zavtra]

Stablecoin may in fact find a home on the exchange, since we are having problems with Gridcoin and there are varying reports on whether the coin actually works as intended or not.

That's good. I would really like to see SBC listed on this exchange as well. It seems like it has a lot of potential (of course I'm a little biased towards it, but I picked it for a reason), and your exchange looks like it has a lot of potential as well.

I'll be following on twitter for updates.

[callawey]

The code posted so far here scares me. Why are you not using mysql prepared statements? You're just asking to be injection attacked.

the code scares me too, i just took a look and a lot of database queries are outside of transaction, actualy there is no transaction at all the system. In such system every single item must be inside a transaction, with this system, i can assure you, in a single lag that your server faces or on a little overload, all the balances on the system will be get crazy.

I suggest you to take the progress to %60 and re-do all your db functioalities, otherwise a big horror movie awaits you.

[r3wt]

Stablecoin may in fact find a home on the exchange, since we are having problems with Gridcoin and there are varying reports on whether the coin actually works as intended or not.

That's good. I would really like to see SBC listed on this exchange as well. It seems like it has a lot of potential (of course I'm a little biased towards it, but I picked it for a reason), and your exchange looks like it has a lot of potential as well.

I'll be following on twitter for updates.

well launch of the site is now postponed in the light of recent posts highlighting some security issues and lack of database transactions, and not using PDO. two things i have no experience with. i wanna do this right so for the time being we are putting launch on stand by while we search for a third dev with the security expertise necessary to complete our dev team. I've spoken with justin and we are willing to admit that we need someone with more experience to shephard us in completing the project.

[northranger79510]

If you guys add Stablecoin, consider me hooked.

[PGomer]

Stablecoin may in fact find a home on the exchange, since we are having problems with Gridcoin and there are varying reports on whether the coin actually works as intended or not.

That's good. I would really like to see SBC listed on this exchange as well. It seems like it has a lot of potential (of course I'm a little biased towards it, but I picked it for a reason), and your exchange looks like it has a lot of potential as well.

I'll be following on twitter for updates.

well launch of the site is now postponed in the light of recent posts highlighting some security issues and lack of database transactions, and not using PDO. two things i have no experience with. i wanna do this right so for the time being we are putting launch on stand by while we search for a third dev with the security expertise necessary to complete our dev team. I've spoken with justin and we are willing to admit that we need someone with more experience to shephard us in completing the project.

I love your approach and attitude. Keep learning and press on!

[zavtra]

well launch of the site is now postponed in the light of recent posts highlighting some security issues and lack of database transactions, and not using PDO. two things i have no experience with. i wanna do this right so for the time being we are putting launch on stand by while we search for a third dev with the security expertise necessary to complete our dev team. I've spoken with justin and we are willing to admit that we need someone with more experience to shephard us in completing the project.

Well I am glad that you are considering SBC, but it is great to see you make sure everything is working properly, rather than doing an incomplete launch and then just barely trekking along like Cryptsy has been doing.

[monsterer]

I suggest you to take the progress to %60 and re-do all your db functioalities, otherwise a big horror movie awaits you.

Ditto

[r3wt]

I suggest you to take the progress to %60 and re-do all your db functioalities, otherwise a big horror movie awaits you.

Ditto

Are you always such a jerk? It's one thing to offer helpful advice, but to make vague negative statements is far from constructive.

[r3wt]

The code posted so far here scares me. Why are you not using mysql prepared statements? You're just asking to be injection attacked.

the code scares me too, i just took a look and a lot of database queries are outside of transaction, actualy there is no transaction at all the system. In such system every single item must be inside a transaction, with this system, i can assure you, in a single lag that your server faces or on a little overload, all the balances on the system will be get crazy.

I suggest you to take the progress to %60 and re-do all your db functioalities, otherwise a big horror movie awaits you.

I would like you to explain this comment to me, particularly since you seem to be suggesting something that doesn't make much sense at all. After researching what has been stated in this thread, all of our queries are blocking operations, so a transaction record queue isn't necessary, but it is useful in case of unforseen error. taking this into consideration, this does not mean we have to restructure all our queries. i can just add a function that encapses the query in a try catch loop. try the query, or catch the exception and rollback. very simple. as far as pdo, yes we will have to convert to prepared statements, but as far as functionality goes, it makes no difference since mysql functions are removed but not deprecated. i'm going to ponder this for a bit, and do some more reading and investigating. i may go get a redbull and a pack of cigarettes and spend the night rewriting our queries. as far as a transaction queue goes though, its a good idea but i am not capable of implementing this alone. i will have to seek a proffessional dba.

[monsterer]

Are you always such a jerk? It's one thing to offer helpful advice, but to make vague negative statements is far from constructive.

Here is some helpful advice: you do not have the necessary knowledge to perform the task you are undertaking. Transactions are absolutely essential in a system like this, to be without them is to be asking questions like this on stack overflow -

http://stackoverflow.com/questions/15026825/php-mysql-how-to-prevent-two-requests-update

Please stop what you are doing. Do some research. Implement some unit tests on your current code to show why it will break, then move to transactions on the same test, confirm the fix and move on.

Cheers, Paul.

[unfocus]

A while back I stepped up to take care of another abandoned exchange project. I became aware of this project, and considered using it since it was 85% done.

Anyway, private beta testing for the Scifi Coin exchange starts tonight. If you want to participate, please register to scificointalk.com and follow instruction http://scificointalk.com/index.php/topic,12.15.html

Bounty available.

[callawey]

The code posted so far here scares me. Why are you not using mysql prepared statements? You're just asking to be injection attacked.

the code scares me too, i just took a look and a lot of database queries are outside of transaction, actualy there is no transaction at all the system. In such system every single item must be inside a transaction, with this system, i can assure you, in a single lag that your server faces or on a little overload, all the balances on the system will be get crazy.

I suggest you to take the progress to %60 and re-do all your db functioalities, otherwise a big horror movie awaits you.

I would like you to explain this comment to me, particularly since you seem to be suggesting something that doesn't make much sense at all. After researching what has been stated in this thread, all of our queries are blocking operations, so a transaction record queue isn't necessary, but it is useful in case of unforseen error. taking this into consideration, this does not mean we have to restructure all our queries. i can just add a function that encapses the query in a try catch loop. try the query, or catch the exception and rollback. very simple. as far as pdo, yes we will have to convert to prepared statements, but as far as functionality goes, it makes no difference since mysql functions are removed but not deprecated. i'm going to ponder this for a bit, and do some more reading and investigating. i may go get a redbull and a pack of cigarettes and spend the night rewriting our queries. as far as a transaction queue goes though, its a good idea but i am not capable of implementing this alone. i will have to seek a proffessional dba.

Let me give you a little example for what i mean:

Code:

                $PricePer = mysql_real_escape_string($_GET["price2"]);
                $Amount = mysql_real_escape_string($_GET["Amount2"]);
                $X = $PricePer * $Amount;
                $Total = file_get_contents("http://openex.pw/system/calculatefees.php?P=" . $X);
                $Fees = file_get_contents("http://openex.pw/system/calculatefees2.php?P=" . $X);
                $user_id = $loggedInUser->user_id; 
                if(TakeMoney($Total,$user_id,$Currency_1) == true)
                {
                        AddMoney($Fees,101,$Currency_1);
                        mysql_query("INSERT INTO trades (`To`,`From`,`Amount`,`Value`,`User_ID`,`Type`,`Fee`,`Total`)VALUES ('$name','$Currency_1a','$Amount','$PricePer','$user_id','$name','$Fees','$Total');");
                }
                else
                {
                        echo "<p class='notify-red' id='notify'>You cannot afford that!</p>";
                }

So, on below code, you have a method AddMoney, which updates a table on mysql, and below it you have an insert query. In that code, there is no guarantity that the insert will work after the update script. Update script can work, but insert may not, so this will cause you a balance issue, as you will deduct the amount from the user but there will be no trade operation. This both queries must be inside one transaction, so one fails, all rollbacks automaticaly, if all succed everything goes fine.

As monsterer stated, you can find a lot of information on this by google'ing or from stackoverflow but without this it will be just a horror movie. You have to change your statements and i can say that by the view of the code, yes you have to change a lot of part on the project

[r3wt]

The code posted so far here scares me. Why are you not using mysql prepared statements? You're just asking to be injection attacked.

the code scares me too, i just took a look and a lot of database queries are outside of transaction, actualy there is no transaction at all the system. In such system every single item must be inside a transaction, with this system, i can assure you, in a single lag that your server faces or on a little overload, all the balances on the system will be get crazy.

I suggest you to take the progress to %60 and re-do all your db functioalities, otherwise a big horror movie awaits you.

I would like you to explain this comment to me, particularly since you seem to be suggesting something that doesn't make much sense at all. After researching what has been stated in this thread, all of our queries are blocking operations, so a transaction record queue isn't necessary, but it is useful in case of unforseen error. taking this into consideration, this does not mean we have to restructure all our queries. i can just add a function that encapses the query in a try catch loop. try the query, or catch the exception and rollback. very simple. as far as pdo, yes we will have to convert to prepared statements, but as far as functionality goes, it makes no difference since mysql functions are removed but not deprecated. i'm going to ponder this for a bit, and do some more reading and investigating. i may go get a redbull and a pack of cigarettes and spend the night rewriting our queries. as far as a transaction queue goes though, its a good idea but i am not capable of implementing this alone. i will have to seek a proffessional dba.

Let me give you a little example for what i mean:

Code:

                $PricePer = mysql_real_escape_string($_GET["price2"]);
                $Amount = mysql_real_escape_string($_GET["Amount2"]);
                $X = $PricePer * $Amount;
                $Total = file_get_contents("http://openex.pw/system/calculatefees.php?P=" . $X);
                $Fees = file_get_contents("http://openex.pw/system/calculatefees2.php?P=" . $X);
                $user_id = $loggedInUser->user_id; 
                if(TakeMoney($Total,$user_id,$Currency_1) == true)
                {
                        AddMoney($Fees,101,$Currency_1);
                        mysql_query("INSERT INTO trades (`To`,`From`,`Amount`,`Value`,`User_ID`,`Type`,`Fee`,`Total`)VALUES ('$name','$Currency_1a','$Amount','$PricePer','$user_id','$name','$Fees','$Total');");
                }
                else
                {
                        echo "<p class='notify-red' id='notify'>You cannot afford that!</p>";
                }

So, on below code, you have a method AddMoney, which updates a table on mysql, and below it you have an insert query. In that code, there is no guarantity that the insert will work after the update script. Update script can work, but insert may not, so this will cause you a balance issue, as you will deduct the amount from the user but there will be no trade operation. This both queries must be inside one transaction, so one fails, all rollbacks automaticaly, if all succed everything goes fine.

As monsterer stated, you can find a lot of information on this by google'ing or from stackoverflow but without this it will be just a horror movie. You have to change your statements and i can say that by the view of the code, yes you have to change a lot of part on the project

Well, we clearly have different definitions of what constitutes being "alot" but thanks for the heads up. now i see exactly what is going wrong and why submitting an order for a negative amount results in that amount being placed into an account. alot of the trading needs to be reworked, but in comparison with the rest of the codebase, that is not much.

Are you always such a jerk? It's one thing to offer helpful advice, but to make vague negative statements is far from constructive.

Here is some helpful advice: you do not have the necessary knowledge to perform the task you are undertaking. Transactions are absolutely essential in a system like this, to be without them is to be asking questions like this on stack overflow -

http://stackoverflow.com/questions/15026825/php-mysql-how-to-prevent-two-requests-update

Please stop what you are doing. Do some research. Implement some unit tests on your current code to show why it will break, then move to transactions on the same test, confirm the fix and move on.

Cheers, Paul.

A little less condescending this time, but still a condescending douchebag. why even bother? You have no idea what knowledge, although i did not know about transactions. Instead we were trying to use a trade history table so we could manually "rollback" in case of error. i think the transaction system is probably the way to go, as both you and calleway said, although you really have yet to say anything helpful, other than being disrespectful. i read what you posted from stack overflow, but you know what? these guys there are the same way as you. they alll talk shit, but never provide any useful knowledge, or a real world example. luckily enough, i was able to find a book on it on kindle and holy crap, never knew this was such a complex subject. i'll be reading and studying up on how we can tackle this. btw, justin did some work on it again last night, moving towards oop again. to practice/learn prepared statements, i began working on building configuration functions, a switch from the variable based system to a system where a 1 or a 0 is stored in the db for each setting. I think realistically, in 1 or 2 weeks we could be done. we'll see how it goes.

[BlueDragon747]

keep up the good work regardless of the % its all progress to the end result

[Sejnt]

Code:

if($_SESSION["Login_Attempts"] > 4)

I didn't see the whole code but this, you know it won't secure anything? A script can remove session cookie easily.

[gielbier]

I don't want to seem negative, but you really should not use mysql anymore. (It will be deprecated in PHP5.5) Use mysqli or PDO instead.