Moving up the ladder!
Top 3% and all!
Enjoy!
Ideas and thoughts about Microsoft Identity, C# development, cabbages and kings and random flotsam on the incoming tide
Thursday, August 29, 2013
Wednesday, August 28, 2013
C# : String with spaces is not null or empty
Came across an interesting case.
I was checking a text field with
String.IsNullOrEmpty
and I noticed that if you enter spaces, it is neither null or empty!
Mr. Google out of bed bright and early and:
String.IsNullOrEmpty() Check for Space
The solution is the "IsNullOrWhiteSpace(string value)" one.
Enjoy!
I was checking a text field with
String.IsNullOrEmpty
and I noticed that if you enter spaces, it is neither null or empty!
Mr. Google out of bed bright and early and:
String.IsNullOrEmpty() Check for Space
The solution is the "IsNullOrWhiteSpace(string value)" one.
Enjoy!
AAD : SSO between AAD and Salesforce
The write-up is here:
Tutorial: Windows Azure AD integration with Salesforce
but I couldn't get it working.
Luckily, I have some SAML experience so figured out the problem.
I posted before about how important it is to get the NameID stuff right and this was indeed the problem.
When you create the user in Salesforce, you have to make sure that the Salesforce username is exactly the same as the login name you use for your AAD tenant.
And you have to use a valid email name.
The email name and username do not have to match.
So assume I log into my AAD tenant as:
jbloggs@tenant.onmicrosoft.com
My email address is jbloggs@gmail.com.
So I create the Salesforce user with:
email = jbloggs@gmail.com
username = jbloggs@tenant.onmicrosoft.com
Check your email - you will get a "Change Password" email from Salesforce.
Change your password.
Login to AAD - navigate to the Access Panel - click Salesforce.
What will happen is that AAD will take your logged in name, put it in a NameID SAML assertion called username and pass it to Salesforce.
Salesforce will check that there is a registered user with that username.
There is so A-OK - you are logged in.
I did not have to synchronise any accounts to achieve this.
Enjoy!
Tutorial: Windows Azure AD integration with Salesforce
but I couldn't get it working.
Luckily, I have some SAML experience so figured out the problem.
I posted before about how important it is to get the NameID stuff right and this was indeed the problem.
When you create the user in Salesforce, you have to make sure that the Salesforce username is exactly the same as the login name you use for your AAD tenant.
And you have to use a valid email name.
The email name and username do not have to match.
So assume I log into my AAD tenant as:
jbloggs@tenant.onmicrosoft.com
My email address is jbloggs@gmail.com.
So I create the Salesforce user with:
email = jbloggs@gmail.com
username = jbloggs@tenant.onmicrosoft.com
Check your email - you will get a "Change Password" email from Salesforce.
Change your password.
Login to AAD - navigate to the Access Panel - click Salesforce.
What will happen is that AAD will take your logged in name, put it in a NameID SAML assertion called username and pass it to Salesforce.
Salesforce will check that there is a registered user with that username.
There is so A-OK - you are logged in.
I did not have to synchronise any accounts to achieve this.
Enjoy!
Monday, August 12, 2013
ASP.NET : Inline validation controls no longer red
So I had a project that I was busy migrating from .NET 3.5 to .NET 4.5.
Now I use the asp:RequiredFieldValidator controls and suddenly I noticed that the error messages were no longer in red.
I then compared the projects - no obvious .ccs changes or anything like that.
Then I compared the web.config files and noticed that:
pages controlRenderingCompatibilityVersion="3.5" clientIDMode="AutoID" validateRequest="false"
had changed to:
pages controlRenderingCompatibilityVersion="4.0" clientIDMode="AutoID" validateRequest="false"
This must have happened during the wizard that migrates the project.
Have a look at:
What's New in ASP.NET 4 and Visual Web Developer
where it mentions that validators no longer render inline color:Red styles.
Changing it back to "3.5" sorted it out.
Isn't red the international error colour anyway?
Enjoy!
Now I use the asp:RequiredFieldValidator controls and suddenly I noticed that the error messages were no longer in red.
I then compared the projects - no obvious .ccs changes or anything like that.
Then I compared the web.config files and noticed that:
pages controlRenderingCompatibilityVersion="3.5" clientIDMode="AutoID" validateRequest="false"
had changed to:
pages controlRenderingCompatibilityVersion="4.0" clientIDMode="AutoID" validateRequest="false"
This must have happened during the wizard that migrates the project.
Have a look at:
What's New in ASP.NET 4 and Visual Web Developer
where it mentions that validators no longer render inline color:Red styles.
Changing it back to "3.5" sorted it out.
Isn't red the international error colour anyway?
Enjoy!
Friday, August 09, 2013
WCF : The request for security token could not be satisfied because authentication failed
In full:
System.ServiceModel.Security.SecurityNegotiationException The caller was not authenticated by the service. System.ServiceModel.FaultException: The request for security token could not be satisfied because authentication failed.
I see this when the WS call is cross domain on wsHttpBinding.
Quick and dirty is to remove the security (or move to basicHttpBinding).
Not recommended on a Production system but to get over the hump …
On the client side change:
<wsHttpBinding>
<binding name="WSHttpBinding_IService" >
<security mode="None" />
</binding>
</wsHttpBinding>
On the WS side change:
<system.serviceModel>
<services>
<service name=xxx">
<endpoint address="" binding="wsHttpBinding" contract="WcfServiceLibrary.IService" bindingConfiguration="NoSecurityConfig">
<identity>
<dns value="yyy" />
</identity>
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
</services>
<bindings>
<wsHttpBinding>
<binding name="NoSecurityConfig">
<security mode="None" />
</binding>
</wsHttpBinding>
</bindings>
Essentially, the changes are to add the “security mode = None” and to add the new bindingConfiguration ="NoSecurityConfig" and then specify the binding for it.
Enjoy!
Subscribe to:
Posts (Atom)