Cross Site Attacks (XSS) what is that all about?
"Cross-site scripting (XSS) is a type of computer security vulnerability typically found in Web applications. XSS enables attackers to inject client-side script into Web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same origin policy. Cross-site scripting carried out on websites accounted for roughly 84% of all security vulnerabilities documented by Symantec as of 2007. Their effect may range from a petty nuisance to a significant security risk, depending on the sensitivity of the data handled by the vulnerable site and the nature of any security mitigation implemented by the site's owner."
All user's inputs can be a back door for attacker to attack your site. User's inputs that we will categorize as un-trusted inputs are :
- Incoming URLs including Request.QueryString[] values
- Form post data (Request.Form[] values including values from hidden fields and disabled fields)
- Cookies
- Data in HTTP Headers (such as Request.UserAgent and Request.UrlReferrer).
Your site could be attacked by altering the query string, form values, or cookies data. The solution is not to prevent request manipulation but to check that each request is a legal request for the logged-in visitor.
Cross-Site Scripting and HTML Injection
If an attacker can get our site to return some javascript to our visitors, then the attacker's script can take control of our visitors' browsing session and by this the attackers can collect the personal information (passwords, credit card details) of our visitors. There are two main ways an attacker follow to get this:
- Persistently: by entering formed malicious input into some feature and hoping we will store it into our database and then issue it back to other visitors.
- Non-persistently or Passively : by finding a way of sending malicious data in a request to our application and having our application echo that data back in it is response. The attacker then finds a way to trick a victim into making such a request.
Razor HTML Encoding
The Razor view engine helps protect us against XSS attacks by encoding any data that we refer to using the @ tag to make it safe to display as HTML. This means when we request an URL with a javascript code as a query string, Razor processes the query string value and replaces the special characters and rendering javascript code as a simple text.
Razor view engine treats the contents of MvcHtmlString objects as if they were encoded, even when that is not the case. We can use Html.Raw helper method to include our HTML into the web page without it being encoded.
Request Validation
The goal of request validation is to stop potentially dangerous data ever reaching the application. If the user tries to submit data that looks like it might be HTML, Then ASP.Net throws an exception. This happens before the request is passed to the MVC Framework, so our application never receives the data the user has sent. But the problem with Request Validation is that it rejects any data even slightly resembling an HTML tag, and this can include valid data.
In ASP.Net MVC Framework, request validation is enabled by default. You can disable it by decorate your controller/action method by ValidateInput attribute and passing false to it. If you decorate the controller with it, that means you enabled/disabled request validation for all action methods within this controller (of course not recommended). If you decorate the action method by that attribute, that means you enabled/disabled request validation for all posted data/model properties. Also you can disable request validation for a specific property by decorate it with AllowHtml attribute.
JavaScript String Encoding and XSS
So what if we want to accept javascript code from the user, i.e post a question on stackoverflow. of course we don't want to refuse it or disable request validation totally. Fortunately, the Ajax helper class has method called JavaScriptStringEncode, which encodes a string so that it safe to display and escapes characters so that JavaScript will understand it. In such case we have to use Html.Raw method around the result generated by the Ajax helper method. If we don't do this, then Razor HTML encodes the result, and we are back where we started. Session Hijacking:
ASP.Net identifies users by session ID cookie which called ASP.Net_SessionId by default, and if we use Forms Authentication, then a second cookie is used called .ASPXAUTH. If an attacker can obtain these cookies, then they can include them in a request to our server and impersonate one of our users. The browser by default preventing the javascript from a site to access cookies of another site. But if the attacker has been able to inject a script into one of our pages, then the browser believes that the script is part of our application and grands access to the session cookies.
We can protect our site by keeping a record of each client IP address when a session starts, we can deny any requests that originate from a different IP. But you should avoid this technique when you deal with the public internet.
We can mark a cookie with the HttpOnly flag, and the browser will hide its existence from javascript but will continue to send it via all HTTP requests. By default ASP.Net marks ASP.Net_SessionId and .ASPXAUTH as HttpOnly. Of course you can apply HttpOnly to your session cookies when you create them.
Cross-Site Request Forgery (CSRF):
Build your MVC application securely
- Don't write any public method inside a controller class that will not be an action method. By default any public method is an action method, other methods should be wrote in model section. If you have to write a method that will not be an action, make sure it will be private or make it public but you must decorate it with NonAction attribute.
- Prevent Model Binding to change sensitive data by using Bind attribute to set up white/black list that restrict which properties model binding is allowed/not allowed to populate.
What is Cross Site Request Forgery (CSRF)?
"A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks."
Cross-site scripting (XSS) is widely regarded as one of the most used security issue on the web. Few developers pay much attention to another form of attack that’s equally destructive and potentially far easier to exploit. Your application can be vulnerable to cross-site request forgery (CSRF) attacks not because you the developer did something wrong (as in, failing to encode outputs leads to XSS), but simply because of how the whole Web is designed to work.
How CSRF works
All web application platforms are potentially vulnerable to CSRF, but in this post we’ll focus on ASP.NET MVC. Imagine you have a controller class as follows:
public class UserProfileController : Controller
{
public ViewResult Edit() { return View(); }
public ViewResult SubmitUpdate()
{
// Get the user's existing profile data (implementation omitted)
ProfileData profile = GetLoggedInUserProfile();
// Update the user object
profile.EmailAddress = Request.Form["email"];
profile.FavoriteHobby = Request.Form["hobby"];
SaveUserProfile(profile);
ViewData["message"] = "Your profile was updated.";
return View();
}
}
This is all very normal. First, the visitor goes to Edit(), which renders some form to let them change their user profile details. Secondly, they post that form to SubmitUpdate(), which saves the changes to their profile record in the database. There’s no XSS vulnerability here. Everything’s fine, right? We implement this sort of thing all the time…
Unfortunately, this innocent controller is an easy target for CSRF. Imagine that an attacker sets up the following HTML page and hosts it on some server of their own:
<body onload="document.getElementById('fm1').submit()">
<form id="fm1" action="http://yoursite/UserProfile/SubmitUpdate" method="post">
<input name="email" value="hacker@somewhere.evil" />
<input name="hobby" value="Defacing websites" />
</form>
</body>
Next, they somehow persuade a victim to visit this page. When this HTML page loads, it submits a valid form post to /UserProfile/SubmitUpdate on your server.
Assuming you’re using Windows authentication or some kind of cookie-based authentication system such as Forms Authentication, the automated form post will be processed within the victim’s established authentication context, and will successfully update the victim’s email address to something under the attacker’s control. All the attacker has to do now is use your “forgotten password” facility, and they’re taken control of the victim’s account.
Of course, instead of changing an victim’s email address, they can perform any action that the victim can perform with a single POST request. For example, they might be able to grant administrative permissions to another account, or post something defamatory to a CMS.
Ways to stop CSRF
There are two main ways to block CSRF:
- Check that incoming requests have a Referer header referencing your domain. This will stop requests unwittingly submitted from a third-party domain. However, some people disable their browser’s Referer header for privacy reasons, and attackers can sometimes spoof that header if the victim has certain versions of Adobe Flash installed. This is a weak solution.
- Put a user-specific token as a hidden field in legitimate forms, and check that the right value was submitted. If, for example, this token is the user’s password, then a third-party can’t forge a valid form post, because they don’t know each user’s password. However, don’t expose the user’s password this way: Instead, it’s better to use some random value (such as a GUID) which you’ve stored in the visitor’s Session collection or into a Cookie.
Using the AntiForgeryToken helpers
The core ASP.NET MVC package includes a set of helpers that give you a means to detect and block CSRF using the “user-specific tokens” technique.
To use these helpers to protect a particular form, put an Html.AntiForgeryToken() into the form, e.g.,
@using(Html.Form("UserProfile", "SubmitUpdate"))
{
@Html.AntiForgeryToken()
<!-- rest of form goes here -->
}
This will output something like the following:
<form action="/UserProfile/SubmitUpdate" method="post">
<input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
<!-- rest of form goes here -->
</form>
At the same time, Html.AntiForgeryToken() will give the visitor a cookie called __RequestVerificationToken, with the same value as the random hidden value shown above.
Next, to validate an incoming form post, add the [ValidateAntiForgeryToken] filter to your target action method. For example,
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc
}
This is an authorization filter that checks that:
- The incoming request has a cookie called __RequestVerificationToken
- The incoming request has a Request.Form entry called __RequestVerificationToken
- These cookie and Request.Form values match
Assuming all is well, the request goes through as normal. But if not, boom!, there’s an authorization failure with message “A required anti-forgery token was not supplied or was invalid”.
This prevents CSRF because even if a potential victim has an __RequestVerificationToken cookie, an attacker can’t find out its value, so they can’t forge a valid form post with the same value in Request.Form. But legitimate users aren’t inconvenienced at all; the mechanism is totally silent
Using salt
Salt? What? In case you want to protect multiple forms in your application independently of each other, you can use a “salt” value when you call Html.AntiForgeryToken(), e.g.,
@Html.AntiForgeryToken("someArbitraryString")
… and also in [ValidateAntiForgeryToken], e.g.,
[ValidateAntiForgeryToken(Salt="someArbitraryString")]
public ViewResult SubmitUpdate()
{
// ... etc
}
Salt is just an arbitrary string. A different salt value means a different anti-forgery token will be generated. This means that even if an attacker manages to get hold of a valid token somehow, they can’t reuse it in other parts of the application where a different salt value is required
Limitations of the Anti-Forgery helpers
ASP.NET MVC’s anti-CSRF helpers work very nicely, but you should be aware of a few limitations:
- All legitimate visitors must accept cookies (otherwise, [ValidateAntiForgeryToken] will deny their form posts). Arguably this isn’t a limitation, because unless visitors allow cookies, you probably don’t have anything to protect anyway.
- It only works with POST requests, not GET requests. Arguably this isn’t a limitation, because under the normal HTTP conventions, you shouldn’t be using GET requests for anything other than read-only operations.
- It’s easily bypassed if you have any XSS holes on your domain. An XSS hole would allow an attacker to read a victim’s anti-forgery token value, then use it to forge valid posts. So, don’t have XSS holes!
- It relies on the potential victim’s browser implementing cross-domain boundaries solidly. Browsers are supposed to stop foreign domains from reading your app’s response text and cookies, and are supposed to stop foreign domains from writing cookies to your domain. If an attacker manages to find a way around this, they can bypass [ValidateAntiForgeryToken]. Of course that’s not supposed to be possible. For the most part, modern browsers block this line of attack.
Links
The Open Web Application Security Project
The orginal article was produced by Steven Sanderson:
Prevent Cross-Site Request Forgery (CSRF) using ASP.NET MVC’s AntiForgeryToken() helper
Following the TDD approach when you are working with MVC it is quite easy to produce Unit Tests that are based on the MVC Controllers, with more and more business logic appearing in the User Interface by using libraries such as jQuery it is becoming more important to perform Unit Testing on JavaScript.
What options are available today, more importantly what are the pros and cons of each solution?
Pros
can be invoked from an ant build file
launches browser to run the tests
Eclipse plug-in
Cons
launches browser to run the tests
Does not support js file to write the unit test code: it has to be embedded inside an html file
it has not been updated for a few years
Notes:
There is a JsUnit (2).
An 'ant' is an open source build tool; "Ant" because it is a little thing that can build big things.
Pros
ant driven
supports js file
very simple to use
Cons
Simulation of JavaScript engine: not advanced enough to support all coding types
Pros
Can be invoked from ant build file
Simulates real browser behaviour
Cons
Simulation of JavaScript engine from a limited number of browser versions
No activity for 2 years: it does not support Firefox versions 2.x nor 3.x
Pros
Runs on actual browser
Cons
JavaScript only framework: cannot be called from ant build file
Pros
Runs on actual browser
Cons
Does not seem to support all code types
JavaScript only framework: cannot be called from ant build file,
Pros
Runs on actual browser
Cons
JavaScript only framework: cannot be called from ant build file
Pros
Can be intergrated with most testing frameworks, such as MSTest, NUnit, xUnit etc
ant build supported
Simple to install, only requires a single dll
Browserless
Can be installed using NuGet
Small overhead of 56k
Cons
Not very active on CodePlex, with only 51 downloads
Reference directly to the js files, so if the js files are moved all the tests need to be updated
I know there are many many more and this is just a cross sample of JavaScript testing libraries, but I think I may have found the crown jewels for TDD.
It looks like JSTest is, not only the only choice we have, it is the simplest and best approach to JavaScript Unit Testing, but why has it only had 51 downloads? Have I found a hidden gem or a monster waiting to bite me?
JSTest does provide an easy way to apply the Test-Driven Development (TDD) process
For an example to use it check out Unit Testing JavaScript with MSTest and JSTest.Net by Shawn Sweeney, I have created a sample MVC application showing it working.
JSTestMVCExample.zip (2.67 mb)
Conclusion, I do think we now have the tools to be fully "TDD" compliant.
JSTest.zip (16.80 kb)
Using the TDD approach in an MVC application, I was wondering how can you ensure that only certain roles have access to the controller. Why should we test for this? Because this is a clearly defined business rule and all business rules need to have Unit Tests where possible.
This is the code, which is quite simple
[Authorize(Roles = "Administrators")]
public class AdminController : Controller
What we need to ensure is that a developer does not come along and add more roles or take away the Administrators roles.
We can do this using a Test and going through the Controller using reflection, like this:
[TestMethod]
public void AdminControllerShouldOnlyAvailableToAdministrators()
{
// Arrange
var attributes = typeof(AdminController).GetCustomAttributes(true).ToList();
var countNonAdministrator = 0;
var countAdministrator = 0;
// Act
foreach (var attribute in
attributes.Where(attribute => attribute.GetType() == typeof(AuthorizeAttribute)).Cast<AuthorizeAttribute>())
{
countNonAdministrator = attribute.Roles.Split(',').ToList().Count(role => role.ToString() != "Administrator");
}
foreach (var attribute in
attributes.Where(attribute => attribute.GetType() == typeof(AuthorizeAttribute)).Cast<AuthorizeAttribute>())
{
countAdministrator = attribute.Roles.Split(',').ToList().Count(role => role.ToString() == "Administrator");
}
// Assert
Assert.IsTrue(countNonAdministrator == 0, "Administrators are only allowed to be authorised to use this controller");
Assert.IsTrue(countAdministrator == 1, "You must only have Administrators to be authorised to use this controller");
}
Team Foundation Server provides the ultimate flexibility in terms of how you arrange our data. Because it simply versions directories and files, and because it describes no particular meaning to any of those objects, you may arrange the data in your repository in any way that we choose. Unfortunately, this flexibility also means that it's easy to find yourself “lost without a roadmap” as you attempt to navigate different Team Foundation Server project repositories that may carry completely different and unpredictable arrangements of the data within them.
To counteract this confusion, you can using a repository layout convention (established long ago) in which a handful of strategically named Team Foundation Server repository directories convey valuable meaning about the data they hold. Most projects have a recognizable “main line”, or trunk, of development; some branches, which are divergent copies of development lines. So we first recommend that each project have a recognizable project root in the repository, a directory under which all of the versioned information for that project—and only that project—lives. Secondly, I suggest that each project root contain a trunk subdirectory for the main development line, a branches subdirectory in which specific branches (or collections of branches) will be created.
In our case branches will contain the developers name followed by the TFS task item they are working on. This makes it very clear at any time who and what was required.
Trunk would be the main body of development, originating from the start of the project until the present.
Branches will be a copy of code derived from a certain point in the trunk that is used for applying major changes to the code while preserving the integrity of the code in the trunk. If the major changes work according to plan, they are usually merged back into the trunk.
Shelve Pending Changes stores your code changes on the server but doesn't commit them to the branch. Here are some reasons for using it:
- To save changes but undo locally when I'm not ready to commit changes but I need to make an emergency bug fix on the same branch.
- To store code for code reviews prior to committing. Other people can check out or view your shelved changes.
- To store changes that are ready for committing when the changes aren't approved yet.
One thing to know about shelving changes: When you unshelve, you get the file as-is. If someone else has modified the file after your shelve, no merge happens. So I don't recommend shelving changes long-term.
Here are some examples of the structure
$abc\src\csp\trunk
$abc\src\csp\branches\David Jason\3243
$abc\src\csp\branches\David Jason\3122
The repository main root has the following structure and shortened names, this is because Visual Studio has a 260 character name length restriction.
src Source Code
dep Deployments
If you are making a large Branch it is recommended that you plan you merge back to your trunk when you branch, as the longer period of time the Branch is separated from the Trunk the more work is going to be required to merge the two back together. As a rule of thumb one week is acceptable where as one month is much too long and will result in a lot of merge conflicts. If the branch is out of the main trunk for more than a month then before the code is merged back to the main trunk full testing of the source will be required, both unit tests and system integration testing which will require to be signed off by the test team that it passes full regression testing before the code is merged back to the main trunk.
With larger branches they can have their own trunk and branches while they are being worked on. If a sub trunk has been created then it is best practice to make sure a build is triggered on all checkins to this trunk to ensure that the code can be build successfully on the build server. It is important that the above paragraph on merging back is adhered to.
I came across this smart little Profiler for SQL Express, or any version of SQL as it happens.
Microsoft SQL Server family includes free Express edition, that is fully functional, however has some disappointing limitations which prevent from using it in development process. One of them is absense of profiling tools, standard SQL profiler is not included. However, I came across this SQL Performance Profiler to use with the express edition for tuning your system.
SQL Server Express Edition Profiler provides most of functionality standard profiler does, such as choosing events to profile, setting filters, etc.
It is a small fee of about $5 for three licences, which is well worth the money.
http://www.datawizard.com
Here is some neat SQL to allow you to search every table and every field in the database for a string
CREATE TABLE myTable99 (TABLE_NAME sysname, COLUMN_NAME sysname, Occurs int)
GO
SET NOCOUNT ON
DECLARE @SQL varchar(8000), @TABLE_NAME sysname, @COLUMN_NAME sysname, @Sargable varchar(80), @Count int
SELECT @Sargable = 'There are too many subscription products resulting from the supplied request data'
DECLARE insaneCursor CURSOR FOR
SELECT c.TABLE_NAME, c.COLUMN_NAME
FROM INFORMATION_SCHEMA.Columns c INNER JOIN INFORMATION_SCHEMA.Tables t
ON t.TABLE_SCHEMA = c.TABLE_SCHEMA AND t.TABLE_NAME = c.TABLE_NAME
WHERE c.DATA_TYPE IN ('char','nchar','varchar','nvarchar','text','ntext')
AND t.TABLE_TYPE = 'BASE TABLE'
OPEN insaneCursor
FETCH NEXT FROM insaneCursor INTO @TABLE_NAME, @COLUMN_NAME
WHILE @@FETCH_STATUS = 0
BEGIN
SELECT @SQL = 'INSERT INTO myTable99 (TABLE_NAME, COLUMN_NAME, Occurs) SELECT '
+ '''' + @TABLE_NAME + '''' + ','
+ '''' + @COLUMN_NAME + '''' + ','
+ 'COUNT(*) FROM [' + @TABLE_NAME
+ '] WHERE [' + @COLUMN_NAME + '] Like '
+ ''''+ '%' + @Sargable + '%' + ''''
--SELECT @SQL
EXEC(@SQL)
IF @@ERROR <> 0
BEGIN
SELECT @SQL
SELECT * FROM INFORMATION_SCHEMA.Columns WHERE TABLE_NAME = @TABLE_NAME
GOTO Error
END
FETCH NEXT FROM insaneCursor INTO @TABLE_NAME, @COLUMN_NAME
END
SELECT * FROM myTable99 WHERE Occurs <> 0
Error:
CLOSE insaneCursor
DEALLOCATE insaneCursor
GO
DROP TABLE myTable99
GO
SET NOCOUNT OFF
The iPhone is the top smartphone, but some Android rivals like the Galaxy S III are very attractive, and they're available in large sizes that the iPhone is not. Plus, they support cool technologies Apple doesn't support.
If you're ensconced in the Apple fold, you may believe you have to stay all-Apple. It turns out that you can bring Android largely into the Apple ecosystem.
Getting iCloud email
Apple's iCloud sync and cloud storage service is one of iOS's and OS X's key attractions. But Apple keeps it in the family to encourage people to commit. However, you can access iCloud email from the standard Android Email app.
The key is to sign in using your iCloud account's me.com address, not your icloud.com address. The incoming server is mail.me.com, and the outgoing server is smtp.me.com. SSL should be on.
Syncing iCloud contacts and calendars
iCloud's auto-syncing contacts and calendars make it supereasy to keep your Mac, iPhone, and iPad up to date with each other. They even work with Windows -- but not Android.
That is, unless you buy two utilities for £3.75 each from developer Marten Gajda: Smoothsync for Cloud Calendar and Smoothsync for Cloud Contacts. Both are available in the Google Play app store.
Sign in with your iCloud credentials, and your Android smartphone is now part of the iCloud family.
Syncing documents
Apple's iCloud Documents feature in iOS -- recently brought to OS X -- can be very handy for keeping documents in sync across all devices you use to access or edit them. It's an Apple-only feature for which there is no way to gain foreign access.
But that's OK. iCloud Documents is quite limited, requiring the same app on each device to read a particular file type. Many apps in iOS aren't on OS X, such as OS X's TextEdit text editor, so iCloud Documents often can't do the job.
You should use Google Drive or DropBox instead; many iOS apps support them natively, and they work on pretty much every mobile and desktop OS today.
Syncing bookmarks and open URLs
Apple's Safari 6 in iOS, OS X, and Windows has a neat feature called iCloud Tabs that syncs the URLs of all open tabs to all other devices using Safari 6 tied to the same iCloud account. Bookmarks are also synced across these three OSes.
Again, there's no way to open up Safari's iCloud tabs and bookmark syncing to Android -- so don't use Safari. Google's Chrome browser has a similar sync capability, and it's available for Android, iOS, OS X, and Windows. (Firefox can also sync across platforms, but recently dropped its iOS sync app; it's not an option if you're using an iPad or other iOS device.)
Find a lost or stolen smartphone
Another great iCloud feature is Find My iPhone, which tracks your iOS and OS X devices, so you can find them on a map, send an alert (in case your phone is hidden under a blanket, for example) or message, and lock or wipe them if necessary. Just be sure you set the device so that a thief can't turn off this feature. Again, Android can't join in.
But there's a comparable service called Lookout that lets you find, lock, or wipe a missing Android device from any browser. The basic version is free. However, be warned that it's easy for a thief to disable it if he or she notices it's installed.
Syncing with iTunes
One of Apple's stickiest technologies is iTunes, which is both a library for your entertainment and store from which to get more of it. Google's free Music Manager app for Windows and OS X syncs nonprotected music wirelessly to your Google Play account, but it must be streamed to your Android device.
A better choice is the free DoubleTwist Player app, which syncs music, videos, and photos. Also, it can transfer these items from iOS device to Android. You need both the Android client and OS X or Windows client. Note that DoubleTwist is full of come-ons for in-app upgrades -- annoyingly so. The $5 AirSync add-on is worthwhile, as it allows Wi-Fi syncing between your computer and Android device.
Streaming to AirPlay
Apple TV is an insidiously useful device, acting as a wireless bridge between Macs and iOS devices for screen mirroring and streaming of movies, music, podcasts, and photos. It too is an Apple-only technology.
But the £5 AirSync add-on utility for DoubleTwist lets you stream music and videos from an Android device to the Apple TV, just as if it were an iPhone or iPad. When it works, that is -- I often could not get the AirTwist streaming icon to appear, and I never did figure out why.
Managing book libraries
iTunes includes the iBookstore, which lets you buy e-books for reading on the iBooks app on an iPad or iPhone, but iBooks doesn't work on other devices, not even Macs. Except for the special Multi-Touch e-book format for the iPad, it's not a great bookstore to use.
Amazon.com's Kindle app is a better choice, as it works on every major mobile and desktop platform, and its book selection is much larger than Apple's.
Getting directions
Everyone knows by now that iOS 6's Apple Maps has major flaws, and Apple has apologized for them. Plus, it provides voice navigation only on an iPhone 4S or iPhone 5. Compare that to Android, whose navigation app has worked well for several years on all Android devices.
But an even better option is the free Waze app; it's available for both iOS and Android. It provides voice navigation on older iPhones, too.
Getting apps
It's a cliché, but a true one: In iOS, there's (very likely) an app for that. Android has a smaller app selection. But you'll find that content apps and services apps (such as for banking, public transit, and airlines) are almost always available for Android if available for iOS. Ditto for basic utilities such as flashlights, social media, restaurant finders, and bar-code scanners.
Have I gone to the dark side and switched over yet, no, I'm still running my iPhone 4s and Google Nexus 4 together. So I'm still sitting on the fence, perhaps the Samsung 4 will tip me over, we'll just have to wait and see.
When you are connecting via a remote connection to a server I find the Shut Down is far far to close to the log off, and if you hit the Shut Down by mistake it can be a devil to get the remote machine to power back up and may require someone to visit the machine to hit the power button.
You can disable the Shut Down button there is a group policy settings for this, start gpedit.msc on the machine or use a domain policy to configure User Configuration - Administrative templates - Start menu. See the setting "Remove and prevent access to the shut down, restart....", change it to enabled.
No more shutting down by accident.
When you develop web application you often have this scenario. Some people are testers, they are testing the application in dev all day, and they want always to test latest version. Moreover testers usually fills data into web application, so they want their data to be preserved between various deploy. If you simply clear all data in test database you will end with a lot of furious tester so do not even think to do this.
If a developer needs to change database schema, we need to automate not only the deploy of the web application, but we need also to sync test database with the latest changes. This is necessary so the test site can work with the new version, but old data is preserved for the happiness of the testers.
This is quite simple using TFS and Database project. The situation is this one
When a developer does a check-in, the build server grabs the tip from TFS, then it runs the builds script and deploy the new version of the site in the test web server. At the same time test database gets updated with the latest database schema.
Next we need the ability to automatically deploy changes to a specific database, this task is quite simple and you can find some details here in msdn, but we need to insert this command into the msbuild script. Here is the code:
<Target Name="AfterDropBuild"><Message Text="Deploy of project database" />
<MSBuild Projects="$(SolutionRoot)srcDbEditionNorthwindTestNorthwindTestNorthwindTest.dbproj"
Properties="OutDir=$(DropLocation)$(BuildNumber)debug;
TargetDatabase=NorthwindCiTest;
DefaultDataPath=C:Program FilesMicrosoft SQL ServerMSSQL.4MSSQLData;
TargetConnectionString=Data Source=VM2003R2_1SQLTEST%3Buser=sa%3Bpwd=Pa$$w0rd;
DeployToDatabase=true;"
Targets="Deploy"/>
</Target>
Original post from Ricci Gian Maria
http://geekswithblogs.net/jakob/archive/2012/04/25/deploying-ssdt-projects-with-tfs-build.aspx