Reminder to migrate to OAuth 2 0 or OpenID Connect

Posted by William Denniss, Product Manager, Identity and Authentication

Over the past few years, we’ve publicized that ClientLogin, OAuth 1.0 (3LO)¹, AuthSub, and OpenID 2.0 were deprecated and would shut down on April 20, 2015. We’re moving away from these older protocols in order to focus support on the latest Internet standards, OAuth 2.0 and OpenID Connect, which increase security and reduce complexity for developers.

The easiest way to migrate to these new standards is to use the Google Sign-in SDKs (see the migration documentation). Google Sign-in is built on top of our OAuth 2.0 and OpenID Connect infrastructure and provides a single interface for authentication and authorization flows on Web, Android and iOS.

If the migration for applications using these deprecated protocols is not completed before the deadline, the application will experience an outage in its ability to connect with Google (possibly including the ability to sign in) until the migration to a supported protocol occurs. To avoid any interruptions in service, it is critical that you work to migrate prior to the shutdown date.

If you need to migrate your integration with Google:

• Migrate from OpenID 2.0 to Google Sign-in
• Migrate from OAuth 1.0 to OAuth 2.0
• For AuthSub and ClientLogin, there is no migration support. You’ll need to start fresh with OAuth 2.0 and users need to re-consent

If you have any technical questions about migrating your application, please post questions to Stack Overflow under the tag google-oauth or google-openid.

¹ 3LO stands for 3-legged OAuth: Theres an end-user that provides consent. In contrast, 2-legged (2LO) correspond to Enterprise authorization scenarios: organizational-wide policies control access. Both OAuth1 3LO and 2LO flows are deprecated.

Read More..

Unlocking bootloader or flashing custom ROM doesnt void your warranty!

Since HTC started htcdev.com with the possibility to unlock bootloader on HTC devices, I noticed that false information and beliefs are spreading around the world and more and more people think (and tell!) other users, that their warranty will be voided after unlocking particular device. This is not true!

In the past I wrote a short article on xda-developers about warranties and why, against common believes, flashing custom ROMs does not void your warranty. You can find this thread here.

Heres some information worth pointing out:

1. Warranty is a contract. In every country there are laws and regulations about warranties, however these vary from place to place and may be slightly different in your country, keep that in mind.
2. If its a contract, then both sides have some obligations and rights. Both - rights and obligations - needs to be written in the warranty, otherwise they doesnt exist. Warranty statements must be consistent with generally applicable law.
3. As a contract, warranty can be created as the parties want, as long as its consistent with generally applicable law.
4. To know exactly whats written in your warranty dont try to Google it - take it out of the box and READ IT. Dont trust what others say - their warranty might be different to your own.

Now, the question is - why unlocking the bootloader doesnt void the warranty? The answer is very simple. Because HTCs warranty contract doesnt state it. The only information about warranty on htcdev.com you can find is this:

So, once again:

"It is our responsibility to caution you that not all claims resulting or caused by or from the unlocking of the bootloader may be covered under warranty."

Is there any information, that unlocking bootloader voids warranty? Nope. So basically, what does it mean? Only this - if you brick your device as a result of e.g. flashing custom ROM (unlocked bootloader allows you doing that), you may have no warranty claim for that particular incident.

Two more important things to conclude:

1. If "not all claims may be covered under warranty", then (logic conversion) some claims may still be covered under warranty.
2. Even if you cant claim something under warranty because it was caused by or from the unlocking of the bootloader, that doesnt mean you have lost your warranty. You still have your warranty and you still can claim under warranty, but this warranty wont cover those particular claims caused by or from the unlocking of the bootloader.

So basically, HTC warns you, that some of the actions you might take after unlocking the bootloader may lead to a situation, when particular issue cant be covered under warranty.

Also, this information on htcdev.com doesnt expand or restrict your warranty terms. It doesnt change it at all. If warranty is given in the paper form, then as a contract the only way to change it, is a paper form too (if not stated otherwise in the warranty itself). HTC just kindly reminds you some sort of information you can conclude from the warranty itself.

Once again, if you are interested why flashing custom ROMs doesnt void warranty as well, please read this thread.

PS. Im also wondering why Samsung users are so crazy about so called flash counter and "Triangle Away" application. They dont need it to have a valid warranty, even with a yellow triangle.

Disclaimer:

This text is just for education purpose. Its not a law itself so you cant base your claims versus a company on this. I may be wrong in many parts - feel free to write a comment under this post and I will make any necessary corrections. I dont know the laws in every country so there may be some slight differences.

Have any questions or comments? Feel free to share! Also, if you like this article, please use media sharing buttons (Twitter, G+, Facebook) below this post!

Read More..

SDK setup error a folder failed to be renamed or moved

During updating your Android SDK components from eclipse (running in windows) you may receive the following error message:
a folder failed to be renamed or moved...

the message suggests that you turn of your anti-virus.
I did so but still recieved the error.
I terminated the adb.exe from the processes but still not solved.

the problem is that the update batch is rin from android.bat file inside tools directory. update requires that this folder is renamed temporarily but since Windows 7 locks it the process halts with this error.
so a workaround for this is to copy the tools folder, paste it in te sdk directory, name it tools_temp for example and run android.bat from this directory.

the update shall go smooth, after finishing delete this temp folder and launch eclipse and it will work fine.

note:
after restarting eclipse you may recieve this error
This Android SDK requires Android Developer Toolkit version 10.xxxxxxxxxx the current version is 9.xxxxxxxxxxxxxx.

this is because the ADT plugin needs to be update after updating software components, go to http://developer.android.com/sdk/eclipse-adt.html and follow the instructions and everything will work after this.

Read More..