Standards love to add things. They remove very little, but they do like to deprecate. This post will describe a collection of things that is heading that way, or not heading that way in C++ 0x.
In my posting on Intention to deprecate trigraphs in the next C++ Standard, we successfully demonstrated that much of the non-English speaking world will still need to rely on trigraphs as a way to get to UCN through "\" which may be inaccessible in some codepages. So we would object to deprecating it without an alternative.
In the last meeting in Santa Cruz, an alternative was proposed in Core issue 789:Replacing Trigraphs. In short, it does not so much deprecate trigraphs (which we like) as move trigraphs out of translation phase 1 so trigraphs are not recognized ahead of raw strings, but is still recognized ahead of other strings (as it is now). It seems that trigraph interaction with raw strings was always the real issue behind the original National Body comment. This interaction had become more prevalent because Raw strings are accepted as part of C++0x. This proposal will level the playing field to what it was again.
We reviewed the paper as a way of fixing the interaction of trigraphs and raw strings. We think the paper is ready to go, but we're holding it back because we're considering other approaches, including moving UCNs out of translation phase 1 or moving raw string recognition into phase 1.
We're still looking at deprecating exception specifications. Our current feeling is that we will deprecate them except for the ways of saying a function doesn't throw at all (e.g., the new noexcept feature, still being reviewed). This feature has been shown to be relatively useless since its inception.
We did a straw poll on deprecating or removing exported templates. I voted to support removal of export to reduce dialecting C++. However a straw poll in full committee seems to prefer deprecation. This feature has been implemented exactly by one company, and even their lead is not opposing its removal. We appreciate their selfless sense of the C++ community and appreciate their sacrifice in learning about why this feature was problematic. Sometimes, it does take doing to see the whole picture.
Finally, we deprecated the semantics of the register keyword. This keyword has been ignored by most compiler that I am aware of, so it is the right time to deprecate it.
As with all deprecation, have no fear. All compilers will generally continue to accept (and or ignore) these cases, so that your code will continue to compile.
Blog Posts
Statistics:
Blogs: 33
Blog Posts: 231
1
2
3
...
16
Previous
Next
Section 2: The Variables view will display all the variables currently in scope. The variables have been divided into two sections: Global variables ("ServiceDemo" in the screenshot) and local variables ("sayHello" in the screenshot); these will be the name of the main part and the name of the function, respectively.
The Breakpoints view displays all the breakpoints in your workspace. One thing worth noting is you can disable breakpoints without deleting them, and there's also a "Skip all breakpoints" option that you might find quite useful.
Picking up where we left off in our example, click on the resume button
to continue execution. You'll be presented with a popup dialog; this dialog is presented when a Service invocation via an Interface part is encountered.
If you have the source code for the target service in your workspace, and you want to be able to step through its code, specify "Use source code", otherwise specify "Use deployed version". If you are invoking a deployed service, then you will need to make sure your EGL deployment descriptor contains a Service client binding which provides information on how to reach the Service. If you don't want to be prompted again for this binding key in the future, you can check the box to save your decision.
Now would be a good time to set a breakpoint in the Service part. Put a breakpoint on line 18 in SayHelloService.egl, which is the first and only line of function hello. Click OK and you should be suspended inside the Service, which runs as a separate process. Click on the resume icon like before and the Service will complete, returining a string back to the Rich UI client.
After the Service has returned data to the client, switch back to your browser to see the results:
Feel free to login and add a comment or question about the debugger.
Justin
After you enter the target Web project, you can specify what to deploy. By default, all Rich UI handlers are listed to deploy, meaning each handler generates an HTML file for each locale specified. If you don't want an HTML endpoint created for a particular handler, since you might not want users to be able to go directly to that URL, click the Rich UI Deployment tab and select which handlers you want to deploy. If you have EGL services that you want to expose as Web services, add them under the Services Deployment tab. We have more on services in a later blog post.
When you finish editing the deployment descriptor, save it. To deploy to the target Web project, click the Deploy the EGL descriptor icon on the top right of the editor window or right-click on the .egldd file and select Deploy EGL descriptor from the menu.
You can view the results in the EGL Deploy Results tab near the bottom of your workspace. Your target Web project should contain JavaScript and Java generated from your source EGL project. For instance, if your EGL project had a Rich UI handler that you selected to deploy, you should see a corresponding HTML file in the WebContent folder. To see the application in action, right-click on the HTML file, select Run As>Run on Server, and select Tomcat 6. The server will start and the file should open running on localhost (or the hostname you specified).
Deployment descriptors let you customize the deployment of your EGL applications. You can create more than one deployment descriptor for each EGL project. For instance, you may want to specify a Web project to deploy your Rich UI handlers and a second one to deploy your services. Each descriptor can be deployed individually (using the Deploy EGL descriptor option) or all at once by right-clicking on the EGL project name and selecting Deploy EGL project.
We hope this helps you understand some of the basics of deploying EGL projects to the Web. We would love to see your EGL applications out there!
Theresa
The intent of the game is simple. You drag the red box labelled "EGL" around with your mouse. All you need to do is avoid the blue boxes and the walls.
How does the game work?
The game essentially consists of two parts: the UI that draws the boxes and let you drag the red box and a service component that can show the top 10 scores. I will describe the two parts in more detail now.
How to avoid Java, C, PHP, and JavaScript
The main algorithm for this game is the following:
The blue boxes shown in the UI are positioned absolutely using a syntax like this:
By making the boxes positioned absolutely, we can place them at any place we want. For this box, the initial location is at x=300 and y=330.
Each time the game timer goes off, we move the blue boxes in a given direction:
For each blue box, we remember its x and y direction. For instance, when it bounces against the right wall, we make its x direction -1. The box is moved simply by giving it a new x and y coordinate. After moving the box, we check to see if we now touch the red box. If so, we stop the game.
The red box itself has drag and drop handlers define on it:
This allows us to start the game and drag the red box while the user moves the mouse:
Finally, when the game stops, we inform the user and display the top 10 scores:
Keeping a Top 10 List
Our top 10 list consists of a little bit of UI, and a service call to report the current score and receive an answer back with the total number of games played and the top 10 games.
The UI is nothing thrilling, other than using a cookie to remember your name:
That same cookie is updated when the user enters a new name, and stored in the browser's cookie jar. Next time the user returns, the stored value will be automatically picked up. Updating a cookie value is as easy as giving it a new value:
The service calls a REST service with 2 URL parameters. It returns a record with inside it an array of top scores. Notice from the definition below that it is not relevant if the service is using XML or JSON to encode its contents. The EGL runtime will determine at runtime how to parse the result.
The service definition looks like this:
To call the service, we use the EGL call statement identifying the service we want to call and what function we want to use when the response arrives in the future:
The top 10 scores are stored in a div that is given an opacity of 0.8, so it is a little bit transparent:
When the answer comes back from the top10 service it is converted automatically by EGL into a set of nested records and we simply add them to our top10 div. Finally, we show the top10 div in the right position:
Using PHP to implement the backend service
All the client code is done in EGL. I decided to place the game on an ISP where I took the cheapest plan available. The plan comes standard with PHP and MySQL. So, I decided to try and use MySQL and PHP to store the high scores to see how that worked.
The MySQL table structure is pretty simple:
I added and IP field to remember where the service came from (which is of course a very limited approach to authentication). I created the table using the phpMyAdmin client that my Internet provider offers.
Then I wrote some PHP and placed it right next to my game's index.html file. Here is what the (insecure) PHP looks like:
Security
My PHP code is highly insecure for various reasons. First, anyone can simply call the URL above and assign any score they like:
Note that I added some sanity checks so that the above URL no longer works
Using a REST service with URL parameters makes it trivial to call in a browser. Tools like Rational AppScan know this and run a huge number of "worst practice" scenarios on a website to find holes like the one I inserted here.
Some ways of making service hacking more difficult would be:
One complicating problem is that our client is written in easy to read JavaScript (compiled from our EGL). That gives hackers a lot of leverage. However, even extreme obfuscation of the JavaScript won't help as hackers can easily use Firebug in Firefox to watch the network traffic and derive what services are used and how to call them. Then they can play the man-in-the-middle game to make the server believe they are the client.
Maybe JavaScript obfuscation combined with service obfuscation has a higher degree of chance of making hackers give up and look for an easier target to hack.
Of course, obscuring thing stops the really silly hacks and even the accidental ones. However, as Andy Tanenbaum used to say when I was stil back in school attending his class on Operating Systems: obscurity is the worst form of security.
Always use SLL and proper authentication to increase security.
Securing the channel and authentication helps to a certain degree. In the end, however, services have to be extremely defensive, paranoid, trace everything, apply statistical analysis, and allow for easy human intervention. Think of your credit card company calling you on your cellphone to verify a suspicious transaction. Also, most comment sections on website have a button to report spam messages or abuse. Any system that runs over the Internet should be assuming the worst and be able to easily recover from abuse.
SQL Injection
One special form of disruptive hacking is to try and make the service run arbitrary code on the hacker's behalf. In our PHP example shown above, we allow for SQL injection very easily.
Then main attack vector in our example is given here:
We retrieve $name and $score from the request URL, and compose a query out of it. If we pass in 'name=Chris' and 'score=32.351', the resulting query would be:
Now, assume someone passes the following parameters to the REST service:
Our query would then look like this:
As "--" starts a comment in SQL, the query now becomes the following two separate SQL statements:
By naively allowing any arguments to be passed to us we allowed random SQL code to be executed on our database. Hackers do not need access to the PHP to come up with this, as automated tools are available to try random fragments until they find one that works.
The simplest solution is to not allow for the script to insert the ';' character. Namely, without that the SQL injection cannot insert a second statement. To avoid further unintentional modifications to the original select statement, we can also check for the single quote character.
To help fight SQL injection, there is a simple PHP trick to sanitize URL parameters. It looks like this:
I added that to the PHP that is currently used by the published game.
Monitoring
In our sample above, we do not monitor client access, other than storing the IP address. Additional information may be collected and stored, such as host name, referer page, browser agent, timestamp, etc. Basically, you should record anything that may help the FBI solve your case once someone drained your server from all its data.
How to really solve security problems
Basically the advise is: Don't try this at home, kids!
Enterprise organizations should not use adhoc security models, of course. The recommendation is to use something like Tivoli Access Manager to control access to, and monitor, their services.
Furthermore, instead of using PHP, you should really write your services in EGL, compile them to Java, and run them on WebSphere, which is proven to be much more secure for Enterprise applications. Using EGL will also make it easier for you to write the service as you will not have to struggle with the quirky syntax of both PHP and MySQL.
Download
To take a look at the client code yourself, download the following attachment and import it as an existing project into your workspace.
Attachment: escape.zip
Now, I am kind of tricking you, as this is not the kind of Portal this blog entry will discuss. However, I cannot help thinking of this game whenever someone asks me if you can do "portals" in EGL Rich UI.
So seriously, when people ask me about Portals there are asking two different questions:
How to build a client-side Portal?
Our starting point is the GadgetContainer sample that comes with EGL CE and that can be found in the Dojo samples project that EGL CE automatically creates for you:
Here is our most reduced version of our Portal:
This produces a portal with 4 empty portlets:
We deployed the second application, in this case Portlet1 in the same location as the main handler, so we use the same base URL to compute the URL for the nested handler. The portlet itself works like a standalone application and can be developed normally using EGL CE. Nothing special is required in its implementation:
The portlets can be dragged around, and here is the result after dragging all the empty ones to the second column:
Our second portlet shows an entry field and a button. Here is the source:
Notice it is waiting for calculator requests by subscribing to "calculator.result" messages on the InfoBus. Whenever any handler on the current page does a publish with that message key, Portlet 2 will be notified in its "showResult" function. When the user presses Enter or clicks the Go button, a multiplication request is published on the InfoBus again, to be picked up by Portlet 3 (see below).
Our third portlet implements a calculator that multiplies a number with 2. Here is the source:
Again, it defines a subscription to the InfoBus, and handles them in its "calculate" function. Once a result is known, we publish it on the InfoBus again. When something unexpected happens, such as arithmetic overflow or the user enters an invalid number, we print a message.
Finally, portlet 4 simply shows another URL, in this case http://ibm.com/
The end result looks like this:
You may have noticed declarations to the following field in some of the portlets:
What this does is include a fix for InfoBus to allow it to work across iframes. Normally a parent and its nested iframes are completely isolated from each other. What the fix allows for is communication between these two different documents.
What if I don't want a Portal?
The above sample shows how to build a client-side Portal using iframes for the individual portlets and InfoBus for communication. You can use the same technique for other compositions of multiple "modules". One example could be having a main handler with a tab folder. As that is all it contains, it will start up quickly. Then as tabs are opened over time, more and more sub-modules are downloaded on demand (using the above IFrame approach).
The nested handlers can be kept around (as in the Portal), but a different policy could be to do some form of "garbage collection" by unloading the iframes from the document, and recreating them from scratch again when the user likes.
By decomposing modules into separate application level URLs, complexity goes down, individual files get smaller, and things will faster initially and will benefit usage patterns where a limited breath of functionality is actually activated by the end user. Some application have hundreds, even thousands of "screens", and putting them all in one single mega-application makes little sense as during any session only a few dozen may be actually activated.
To try this out in your own workspace, import the attached archive as "General > Existing projects into Workspace". Open the Portal.egl application and load it in the preview.
To try out the non-Portal approach, check out "AppSwitcher.egl".
Attachments: Portal.zip
To derprecate or not deprecate, that is the question. in C++ Standard
Posted by Michael_Wong Nov 6, 2009
The View (or trip report) from the Oct 2009 C++ Standard meeting Part 2 in C++ Standard
Posted by Michael_Wong Nov 6, 2009
The View (or trip report) from the Oct 2009 C++ Standard meeting in C++ Standard
Posted by Michael_Wong Nov 5, 2009
The View (or trip report) from the Oct 2009 C Standard meeting in C Standard
Posted by Michael_Wong Nov 2, 2009
In EGL CE you are able to debug both the Rich UI front-ends, as well as the Service back-ends. All debug sessions must begin with the Rich UI application. There are several ways to initiate a debug session, such as right-clicking a RUIHandler file and selecting Debug EGL Rich UI Application:
Or if you have the editor open, switch to the Preview tab and click on the Debug icon:
Once your debug session begins, the Rich UI application will be loaded in an external Web browser. Your default system Web browser will be used, but this can be changed in Window > Preferences > General > Web Browser.
Another preference page worth mentioning is EGL > Debug. The EGL CE help system has detailed descriptions about the debugger preferences, as well as which preferences apply to Services and which apply to RUIHandler parts.
If you're not familiar with developing in Eclipse, breakpoints can be added to your EGL source files by double-clicking inside the left margin of the source editor. If a breakpoint marker doesn't appear, that means it's not a valid location for a breakpoint. You can also right-click inside the left margin to add/remove/disable breakpoints.
As an example, let's use the ServiceDemo.egl sample, inside project com.ibm.egl.rui.samples.ce. Place a breakpoint at line 59, which is the first line of function sayHello. Now start the debug session for this handler. After the page is loaded in the external browser, enter your name and click the Say Hello button; the EGL CE workbench should be activated and you'll be prompted to switch to the Debug perspective. Click OK, optionally checking the box to automatically take this action in the future, and you should see the following:
I have highlight two sections in the screenshot above.
Section 1: The Debug view contains the debug stack, which is the stack of funtions currently being executed, and is only visible when you're suspended. The toolbar in this view can be used for the typical debugging commands: step into, step over, step return, resume, terminate, and suspend.
Tip: If you accidentally coded an infinite loop, or something is taking an incredibly long time to execute and you're curious why, you can click on the suspend button  to pause the debugger. If no code is currently running when you click suspend (e.g. browser is waiting for a user event), then the debugger will immediately pause the next time any of your code is run. |
Section 2: The Variables view will display all the variables currently in scope. The variables have been divided into two sections: Global variables ("ServiceDemo" in the screenshot) and local variables ("sayHello" in the screenshot); these will be the name of the main part and the name of the function, respectively.
The Breakpoints view displays all the breakpoints in your workspace. One thing worth noting is you can disable breakpoints without deleting them, and there's also a "Skip all breakpoints" option that you might find quite useful.
Tip: Hover the mouse over a variable that's in scope while suspended, and you'll get a tooltip containing its value: |
Picking up where we left off in our example, click on the resume button
to continue execution. You'll be presented with a popup dialog; this dialog is presented when a Service invocation via an Interface part is encountered. If you have the source code for the target service in your workspace, and you want to be able to step through its code, specify "Use source code", otherwise specify "Use deployed version". If you are invoking a deployed service, then you will need to make sure your EGL deployment descriptor contains a Service client binding which provides information on how to reach the Service. If you don't want to be prompted again for this binding key in the future, you can check the box to save your decision.
Now would be a good time to set a breakpoint in the Service part. Put a breakpoint on line 18 in SayHelloService.egl, which is the first and only line of function hello. Click OK and you should be suspended inside the Service, which runs as a separate process. Click on the resume icon like before and the Service will complete, returining a string back to the Rich UI client.
| Tip: You can step into a Service invocation just like you would step into a function. This will kick off the service and immediately continue to the next line of the Rich UI code. The Rich UI code can be run in parallel with the Service code, since they are in separate processes, and the Service callback function (or error function) will be run once the Service completes and the Rich UI function stack is empty. |
After the Service has returned data to the client, switch back to your browser to see the results:
Feel free to login and add a comment or question about the debugger.
Justin
Demistifying zOS Include files in Commercial Computing with C/C++
Posted by VolodymyrPaprotski Oct 15, 2009
While you are developing your EGL project, you can run it using the Preview tab and using the debugging tools. You can even try out services that you have written or ones from third parties. Testing your application this way saves a lot of time and effort over other development tools that require you to deploy to confirm any changes behave as you expect.
When you are satisfied with your application, you can deploy it to a Web application server such as Apache Tomcat version 6. EGL projects aren't directly deployed to an application server; EGL projects are deployed as dynamic Web projects. EGL source code is generated as Java and JavaScript in the Web project.
To create your target Web project, open the deployment descriptor file (.egldd) located in the EGLSource directory of your EGL project. The deployment descriptor specifies where to deploy - the target Web project (including the target runtime server), and what to deploy - the Rich UI handlers and services.
In the deployment descriptor editor, click New next to the Target name field to open the New Dynamic Web project wizard. Enter the name of your Web project. Select Apache Tomcat v6.0 as the target runtime. If you haven't created a server, you can click New next to the Target runtime field, which opens the New Server Runtime Environment wizard. Select Apache Tomcat v6.0 from the list of servers and click Next. If you have Tomcat installed, you can browse to the installation directory. If you don't have Tomcat installed, you can click Download and Install, accept the license agreement, and click OK. (Note: watch the lower right-hand corner of the workbench for progress. If for some reason you get an error, I recommend going to the Apache site and downloading and installing Tomcat then just point to it.)
After you enter the target Web project, you can specify what to deploy. By default, all Rich UI handlers are listed to deploy, meaning each handler generates an HTML file for each locale specified. If you don't want an HTML endpoint created for a particular handler, since you might not want users to be able to go directly to that URL, click the Rich UI Deployment tab and select which handlers you want to deploy. If you have EGL services that you want to expose as Web services, add them under the Services Deployment tab. We have more on services in a later blog post.
When you finish editing the deployment descriptor, save it. To deploy to the target Web project, click the Deploy the EGL descriptor icon on the top right of the editor window or right-click on the .egldd file and select Deploy EGL descriptor from the menu.
You can view the results in the EGL Deploy Results tab near the bottom of your workspace. Your target Web project should contain JavaScript and Java generated from your source EGL project. For instance, if your EGL project had a Rich UI handler that you selected to deploy, you should see a corresponding HTML file in the WebContent folder. To see the application in action, right-click on the HTML file, select Run As>Run on Server, and select Tomcat 6. The server will start and the file should open running on localhost (or the hostname you specified).
Deployment descriptors let you customize the deployment of your EGL applications. You can create more than one deployment descriptor for each EGL project. For instance, you may want to specify a Web project to deploy your Rich UI handlers and a second one to deploy your services. Each descriptor can be deployed individually (using the Deploy EGL descriptor option) or all at once by right-clicking on the EGL project name and selecting Deploy EGL project.
We hope this helps you understand some of the basics of deploying EGL projects to the Web. We would love to see your EGL applications out there!
Theresa
How to properly waste your time using EGL in EGL Community Edition
Posted by ChrisLaffra Sep 26, 2009Today, I wrote a game in EGL Rich UI inspired by the well-known web game called "Escape", "Escapa", "The Red Box Game", or whatever name the latest inspired copier decided to give before hosting it on their own homepage. I am still trying to find out who really wrote the original.
Anyway, it looks like this:
See http://eglplanner.com/escape
The intent of the game is simple. You drag the red box labelled "EGL" around with your mouse. All you need to do is avoid the blue boxes and the walls.
How does the game work?
The game essentially consists of two parts: the UI that draws the boxes and let you drag the red box and a service component that can show the top 10 scores. I will describe the two parts in more detail now.
How to avoid Java, C, PHP, and JavaScript
The main algorithm for this game is the following:
- place a red box in the middle and allow the user to drag it
- place four blue boxes elsewhere and give each a unique motion vector
- start a new job to run each X milliseconds to move each blue box
- when the red box goes outside the white box or overlaps with a blue box, stop
- every 10 seconds decrease the value of X so the blue boxes will move faster
The blue boxes shown in the UI are positioned absolutely using a syntax like this:
new Div {
position = "absolute", x = 300, y = 330,
width = 100, height = 20,
color = "white", background = "navy", font = "Arial",
innerHTML = "<center style='margin-top: 1px'>JavaScript</center>"
}
By making the boxes positioned absolutely, we can place them at any place we want. For this box, the initial location is at x=300 and y=330.
Each time the game timer goes off, we move the blue boxes in a given direction:
moveEnemy(enemies[2], -12, -20);
For each blue box, we remember its x and y direction. For instance, when it bounces against the right wall, we make its x direction -1. The box is moved simply by giving it a new x and y coordinate. After moving the box, we check to see if we now touch the red box. If so, we stop the game.
function moveEnemy(enemy Div, x int in, y int in)
directionX int = enemy.getAttribute("directionX");
directionY int = enemy.getAttribute("directionY");
if (touchesVerticalWall(enemy))
directionX *= -1;
enemy.setAttribute("directionX", directionX);
end
if (touchesHorizontalWall(enemy))
directionY *= -1;
enemy.setAttribute("directionY", directionY);
end
enemy.x += x * directionX;
enemy.y += y * directionY;
if (enemyTouches(enemy))
stop("a blue box");
end
end
The red box itself has drag and drop handlers define on it:
red Div {
onStartDrag = startDrag, onDrag = drag, onDropOnTarget = endDrag,
cursor = "pointer",
position = "absolute", x= 205, y = 205, width = 40, height = 40,
background = "darkred", color = "white", font = "Arial",
innerHTML = "<center style='margin-top: 9px'>EGL</center>"
};
This allows us to start the game and drag the red box while the user moves the mouse:
function startDrag(widget Widget in, x int in, y int in) returns(boolean)
dx = x - red.x;
dy = y - red.y;
start();
return (true);
end
function drag(widget Widget in, target Widget in, x int in, y int in)
if (!stopped)
red.x = x - dx;
red.y = y - dy;
end
if (outsidewhite())
stop("the black border");
end
end
function endDrag(widget Widget in, target Widget in, x int in, y int in)
end
Finally, when the game stops, we inform the user and display the top 10 scores:
function stop(reason String in)
message.text = "You touched "+reason+". Drag the red box to start.";
reset();
stopped = true;
top10.score = (browser.currentTimeMillis() - startTime)/1000;
end
Keeping a Top 10 List
Our top 10 list consists of a little bit of UI, and a service call to report the current score and receive an answer back with the total number of games played and the top 10 games.
The UI is nothing thrilling, other than using a cookie to remember your name:
nameLabel TextLabel { text = "Your Name: " };
cookie Cookie { key = "name" };
nameField TextField { width = 80, text = cookie.value, onKeyUp ::= setName };
That same cookie is updated when the user enters a new name, and stored in the browser's cookie jar. Next time the user returns, the stored value will be automatically picked up. Updating a cookie value is as easy as giving it a new value:
function setName(e Event in)
if (nameField.text != "")
cookie.value = nameField.text;
end
end
The service calls a REST service with 2 URL parameters. It returns a record with inside it an array of top scores. Notice from the definition below that it is not relevant if the service is using XML or JSON to encode its contents. The EGL runtime will determine at runtime how to parse the result.
The service definition looks like this:
interface HighScores
function getTop10(name String in, score float in) returns(HighScoresRecord)
{@GetRest {
uriTemplate="http://eglplanner.com/escape/highscore.php?name={name}&score={score}"
}};
end
record Result
total int;
top10 ScoreRecord[0];
end
record Score
name String;
value float;
end
To call the service, we use the EGL call statement identifying the service we want to call and what function we want to use when the response arrives in the future:
function setScore(score float in)
this.score = score;
scoreField.text = "Score: "+score;
call svc.getTop10(nameField.text, score) returning to handleTop10 onException ServiceLib.serviceExceptionHandler;
end
The top 10 scores are stored in a div that is given an opacity of 0.8, so it is a little bit transparent:
top10 Div {
position = "absolute", x = -100, y = 5,
*opacity = 0.8*, padding = 10, background = "black",
borderColor = "red", borderWidth = 12, borderStyle = "solid"
};
When the answer comes back from the top10 service it is converted automatically by EGL into a set of nested records and we simply add them to our top10 div. Finally, we show the top10 div in the right position:
function handleTop10(result HighScoresRecord in)
s String = "Total plays: <b>"+result.total + "</b>. " +
"Your score: <b>"+score+"s</b>.<p>" +
"Here are the Top 10 scores:" +
"<table border=1 width=300 cellpadding=3 style:'margin:10px; opacity: 1.0'>";
for (n int from 1 to result.top10.getSize())
score ScoreRecord = result.top10[n];
s += "<tr><td>" + n + "</td><td>" + score.value +
"s</td><td> " + score.name + "</td></tr>";
end
s += "</table>";
top10.innerHTML = s;
top10.x = scoreField.x + scoreField.pixelWidth + 15;
ui.table.setAttribute("valign", "top");
showTop10(true);
end
function showTop10(value boolean in)
if (value)
ui.appendChild(top10);
else
ui.removeChild(top10);
end
end
Using PHP to implement the backend service
All the client code is done in EGL. I decided to place the game on an ISP where I took the cheapest plan available. The plan comes standard with PHP and MySQL. So, I decided to try and use MySQL and PHP to store the high scores to see how that worked.
The MySQL table structure is pretty simple:
name varchar(64)
score float
ip varchar(32)
I added and IP field to remember where the service came from (which is of course a very limited approach to authentication). I created the table using the phpMyAdmin client that my Internet provider offers.
Then I wrote some PHP and placed it right next to my game's index.html file. Here is what the (insecure) PHP looks like:
<?
$host = "localhost";
$user = "*********";
$pass = "*********";
$db = "highscores";
$name = $_REQUEST['name'];
$score = $_REQUEST['score'];
$ip = $_SERVER['REMOTE_ADDR'];
$connection = mysql_connect($host, $user, $pass) or die ("Unable to connect!");
mysql_select_db($db) or die ("Cannot open database $db");
if (isset($name) && isset($score)) {
$query = "INSERT INTO highscores(name, score, ip) VALUES('$name', '$score', '$ip')";
$result = mysql_query($query);
}
$query = "SELECT * FROM highscores";
$result = mysql_query($query);
$total = mysql_num_rows($result);
$query = "SELECT * FROM highscores ORDER BY score + 0 DESC LIMIT 10";
$result = mysql_query($query);
echo "<result><total>$total</total>";
if (mysql_num_rows($result) > 0) {
while($row = mysql_fetch_row($result)) {
echo "<score><name>$row[0]</name><value>$row[1]</value></score>";
}
}
echo "</result>";
mysql_close($connection);
?>
Security
My PHP code is highly insecure for various reasons. First, anyone can simply call the URL above and assign any score they like:
Hack your own score
Note that I added some sanity checks so that the above URL no longer works
Using a REST service with URL parameters makes it trivial to call in a browser. Tools like Rational AppScan know this and run a huge number of "worst practice" scenarios on a website to find holes like the one I inserted here.
Some ways of making service hacking more difficult would be:
- Use a POST and place the arguments in the message body, instead of on the URL.
- Use some "secret" encoding for the message that only the client and the service know about.
One complicating problem is that our client is written in easy to read JavaScript (compiled from our EGL). That gives hackers a lot of leverage. However, even extreme obfuscation of the JavaScript won't help as hackers can easily use Firebug in Firefox to watch the network traffic and derive what services are used and how to call them. Then they can play the man-in-the-middle game to make the server believe they are the client.
Maybe JavaScript obfuscation combined with service obfuscation has a higher degree of chance of making hackers give up and look for an easier target to hack.
Of course, obscuring thing stops the really silly hacks and even the accidental ones. However, as Andy Tanenbaum used to say when I was stil back in school attending his class on Operating Systems: obscurity is the worst form of security.
Always use SLL and proper authentication to increase security.
Securing the channel and authentication helps to a certain degree. In the end, however, services have to be extremely defensive, paranoid, trace everything, apply statistical analysis, and allow for easy human intervention. Think of your credit card company calling you on your cellphone to verify a suspicious transaction. Also, most comment sections on website have a button to report spam messages or abuse. Any system that runs over the Internet should be assuming the worst and be able to easily recover from abuse.
SQL Injection
One special form of disruptive hacking is to try and make the service run arbitrary code on the hacker's behalf. In our PHP example shown above, we allow for SQL injection very easily.
Then main attack vector in our example is given here:
$name = $_REQUEST['name'];
$score = $_REQUEST['score'];
...
$query = "INSERT INTO highscores(name, score, ip) VALUES('$name', '$score', '$ip')";
We retrieve $name and $score from the request URL, and compose a query out of it. If we pass in 'name=Chris' and 'score=32.351', the resulting query would be:
INSERT INTO highscores(name, score, ip) VALUES('Chris', '32.351', '192.168.0.1')";
Now, assume someone passes the following parameters to the REST service:
name=x',1,foo); DROP TABLE highscores; --
Our query would then look like this:
INSERT INTO highscores(name, score, ip) VALUES('x',1,foo); DROP TABLE highscores; --', '32.351', '192.168.0.1')";
As "--" starts a comment in SQL, the query now becomes the following two separate SQL statements:
INSERT INTO highscores(name, score, ip) VALUES('x',1,foo);
DROP TABLE highscores;
By naively allowing any arguments to be passed to us we allowed random SQL code to be executed on our database. Hackers do not need access to the PHP to come up with this, as automated tools are available to try random fragments until they find one that works.
The simplest solution is to not allow for the script to insert the ';' character. Namely, without that the SQL injection cannot insert a second statement. To avoid further unintentional modifications to the original select statement, we can also check for the single quote character.
To help fight SQL injection, there is a simple PHP trick to sanitize URL parameters. It looks like this:
$name = mysql_real_escape_string($_REQUEST['name']);
$score = mysql_real_escape_string($_REQUEST['score']);
I added that to the PHP that is currently used by the published game.
Monitoring
In our sample above, we do not monitor client access, other than storing the IP address. Additional information may be collected and stored, such as host name, referer page, browser agent, timestamp, etc. Basically, you should record anything that may help the FBI solve your case once someone drained your server from all its data.
How to really solve security problems
Basically the advise is: Don't try this at home, kids!
Enterprise organizations should not use adhoc security models, of course. The recommendation is to use something like Tivoli Access Manager to control access to, and monitor, their services.
Furthermore, instead of using PHP, you should really write your services in EGL, compile them to Java, and run them on WebSphere, which is proven to be much more secure for Enterprise applications. Using EGL will also make it easier for you to write the service as you will not have to struggle with the quirky syntax of both PHP and MySQL.
Download
To take a look at the client code yourself, download the following attachment and import it as an existing project into your workspace.
Attachment: escape.zip
Developing a Portal using EGL Rich UI - Bending the Laws of Physics in EGL Community Edition
Posted by ChrisLaffra Sep 24, 2009Why Portals?
One of the most inspiring video games I have ever seen is the Aperture Science Enrichment Center, also known as Portal. It bends the law of physics in very interesting patterns:
Image/article source: Wired Magazine
Now, I am kind of tricking you, as this is not the kind of Portal this blog entry will discuss. However, I cannot help thinking of this game whenever someone asks me if you can do "portals" in EGL Rich UI.
So seriously, when people ask me about Portals there are asking two different questions:
- How can I write an EGL Rich UI application and use it inside a WebSphere Portal? In essence a Rich UI application is really an HTML file with some JavaScript embedded inside it. That can be produced by a JSR 286 portlet. We may have time to dive deeper into that in a future blog. What I really want to discuss is the next question...
- How can I write a Rich UI application that has a main Rich UI handler and that downloads other RUI handlers on demand and make them appear as being a integral component of the larger application. In other words, how can I make a client-side Portal? That question is really the topic of this blog entry.
How to build a client-side Portal?
Our starting point is the GadgetContainer sample that comes with EGL CE and that can be found in the Dojo samples project that EGL CE automatically creates for you:
First step is to reduce that sample to something a bit simpler, and then use other applications (preferably done in EGL Rich UI) to occupy the various portlets.
Here is our most reduced version of our Portal:
Handler Portal Type RUIHandler{ initialUI = [ ui ] }
ui GadgetContainer { columns = 2, columnWidth = 150, gadgets = [
new Gadget { title = "Portlet1", column = 1, children = [] },
new Gadget { title = "Portlet2", column = 2, children = [] },
new Gadget { title = "Portlet3", column = 1, children = [] },
new Gadget { title = "Portlet4", column = 2, children = [] }
]};
end
This produces a portal with 4 empty portlets:
Now, we will place an iframe into one of the portlets and insert another EGL Rich UI application inside it:
Handler Portal Type RUIHandler{ initialUI = [ ui ] }
ui GadgetContainer { columns = 2, columnWidth = 150, gadgets = [
new Gadget { title = "Portlet1", column = 1, children = [
new IFrame {
width = 135, height = 150, src = getURL("Portlet1")
}
] },
new Gadget { title = "Portlet2", column = 2, children = [] },
new Gadget { title = "Portlet3", column = 1, children = [] },
new Gadget { title = "Portlet4", column = 2, children = [] }
]};
function getURL(name String in) returns(String)
pkg String = "com/ibm/egl/demos";
baseURL String = document.location;
baseURL = baseURL[1 : strlib.indexOf(baseURL, pkg)-1];
return (baseURL + pkg + "/" + name + ".html");
end
end
We deployed the second application, in this case Portlet1 in the same location as the main handler, so we use the same base URL to compute the URL for the nested handler. The portlet itself works like a standalone application and can be developed normally using EGL CE. Nothing special is required in its implementation:
handler Portlet1 type RUIhandler {initialUI = [ html ] }
html HTML {
padding = 2,
text =
"This <b>portlet</b> contains <i>just</i> some HTML. That's it.<p>" +
"Visit <a target=_blank href=http://ibm.com>ibm.com</a>."
};
The portlets can be dragged around, and here is the result after dragging all the empty ones to the second column:
Now let's add a more interesting portlet, such as one where two portlets communicate with each other. We will use the EGL InfoBus, which is based on the standard OpenAjax Hub to send messages between the portal and its portlets.
Our second portlet shows an entry field and a button. Here is the source:
handler Portlet2 type RUIhandler {initialUI = [ html, numberField, goButton ] }
html HTML {
margin = 7, font = "Arial", text = "Enter a number:"
};
numberField TextField {
margin = 7, marginTop = 4, onKeyPress ::= checkEnter, text = "2"
};
goButton DojoButton {
text = "Go", margin = 7, onClick ::= go
};
subscription any = InfoBus.subscribe("calculator.result", showResult);
function go(e Event in)
InfoBus.publish("calculator.calculate", numberField.text);
end
function checkEnter(e Event in)
if (e.ch == 13)
go(e);
end
end
function showResult(msg String in, result any in)
numberField.text = result;
end
fix CrossIFrameInfoBusFix{};
end
Notice it is waiting for calculator requests by subscribing to "calculator.result" messages on the InfoBus. Whenever any handler on the current page does a publish with that message key, Portlet 2 will be notified in its "showResult" function. When the user presses Enter or clicks the Go button, a multiplication request is published on the InfoBus again, to be picked up by Portlet 3 (see below).
Our third portlet implements a calculator that multiplies a number with 2. Here is the source:
handler Portlet3 type RUIhandler {initialUI = [ html ] }
html HTML { font = "Arial", text = "Waiting for Portlet 2..." };
subscription any = InfoBus.subscribe("calculator.calculate", calculate);
function calculate(msg String in, data any in)
try
value bigint = data;
result bigint = 2 * value;
html.text = "2 * " + value + " = " + result;
InfoBus.publish("calculator.result", result as String);
onException (e AnyException)
html.text = "Oops: '" + e.message + " " + data + "'";
end
end
fix CrossIFrameInfoBusFix{};
end
Again, it defines a subscription to the InfoBus, and handles them in its "calculate" function. Once a result is known, we publish it on the InfoBus again. When something unexpected happens, such as arithmetic overflow or the user enters an invalid number, we print a message.
Finally, portlet 4 simply shows another URL, in this case http://ibm.com/
handler Portlet4 type RUIhandler {initialUI = [ frame ] }
frame IFrame { width=1000, height=1000, src = "http://ibm.com" };
end
The end result looks like this:
Inter-portlet Communication
You may have noticed declarations to the following field in some of the portlets:
fix CrossIFrameInfoBusFix{};
What this does is include a fix for InfoBus to allow it to work across iframes. Normally a parent and its nested iframes are completely isolated from each other. What the fix allows for is communication between these two different documents.
What if I don't want a Portal?
The above sample shows how to build a client-side Portal using iframes for the individual portlets and InfoBus for communication. You can use the same technique for other compositions of multiple "modules". One example could be having a main handler with a tab folder. As that is all it contains, it will start up quickly. Then as tabs are opened over time, more and more sub-modules are downloaded on demand (using the above IFrame approach).
The nested handlers can be kept around (as in the Portal), but a different policy could be to do some form of "garbage collection" by unloading the iframes from the document, and recreating them from scratch again when the user likes.
By decomposing modules into separate application level URLs, complexity goes down, individual files get smaller, and things will faster initially and will benefit usage patterns where a limited breath of functionality is actually activated by the end user. Some application have hundreds, even thousands of "screens", and putting them all in one single mega-application makes little sense as during any session only a few dozen may be actually activated.
To try this out in your own workspace, import the attached archive as "General > Existing projects into Workspace". Open the Portal.egl application and load it in the preview.
To try out the non-Portal approach, check out "AppSwitcher.egl".
Attachments: Portal.zip
