Error:1411809D:SSL routines - When trying to make https call from inside R module in AzureML - r

I have an experiment in AzureML which has a R module at its core. Additionally, I have some .RData files stored in Azure blob storage. The blob container is set as private (no anonymous access).
Now, I am trying to make a https call from inside the R script to the azure blob storage container in order to download some files. I am using the httr package's GET() function and properly set up the url, authentication etc...The code works in R on my local machine but the same code gives me the following error when called from inside the R module in the experiment
error:1411809D:SSL routines:SSL_CHECK_SERVERHELLO_TLSEXT:tls invalid ecpointformat list
Apparently this is an error from the underlying OpenSSL library (which got fixed a while ago). Some suggested workarounds I found here were to set sslversion = 3 and ssl_verifypeer = 1, or turn off verification ssl_verifypeer = 0. Both of these approaches returned the same error.
I am guessing that this has something to do with the internal Azure certificate / validation...? Or maybe I am missing or overseeing something?
Any help or ideas would be greatly appreciated. Thanks in advance.
Regards

After a while, an answer came back from the support team, so I am going to post the relevant part as an answer here for anyone who lands here with the same problem.
"This is a known issue. The container (a sandbox technology known as "drawbridge" running on top of Azure PaaS VM) executing the Execute R module doesn't support outbound HTTPS traffic. Please try to switch to HTTP and that should work."
As well as that a solution is on the way :
"We are actively looking at how to fix this bug. "
Here is the original link as a reference.
hth

Related

Not able to connect to my Google Account using gconnect function of gtrendsR package

In order to start working with the newly developed package "gtrendsR" (the version 1.3.1 released by 2015-12-10) which in fact is a package to Perform and Display Google Trends Queries, you should connect to a google account. I have tried it several times to connect to my gmail account just as it is written in the instructions, but I have not been able to connect yet.
gconnect("usr#gmail.com", "psw")
It gives me this error:
Error in function (type, msg, asError = TRUE) :
Operation timed out after 0 milliseconds with 0 out of 0 bytes received
I have no idea how to fix it guys...!!??
Package Co-Maintainer here. We write about this in README.md and in the help page.
Maybe you have you two-factor authentication? Maybe you are behind some type of firewall and you need to try out in the open? It "works for me" with a dedicated account I created for Google Trends; others use the same trick.
If you file an issue ticket, or better still, read the existing discussion over there, you may get some better help. Right now your question is unanswerable due to lack of specifics or reproducible results.
As Dirk Eddelbuettel wrote, this might be because you are behind a Firewall. If so, you can either unblock the port that you are using for connecting or alternatively use a Proxy Server (I received the same error as you, until I configured a proxy).
For Information on how to configure Internet Access via Proxy in Rstudio see:
RStudio Proxy Configuration on Windows
or
https://support.rstudio.com/hc/en-us/articles/200488488-Configuring-R-to-Use-an-HTTP-or-HTTPS-Proxy
For Setting Proxies in R see:
http://stat.ethz.ch/R-manual/R-patched/library/utils/html/download.file.html

Work around in RGoogleDocs with two-step verification?

I try to use RGoogleDocs and get
Error: Forbidden
I have two-step verification on: is there a work-around?
sheets.con = getGoogleDocsConnection(getGoogleAuth(user, ps, service = "wise"))
Error: Forbidden
Relevant question
The getGoogleAuth of RGoogleDocs package is based on an officially deprecated ClientLogin to connect google server, see https://developers.google.com/identity/protocols/AuthForInstalledApps?csw=1
You may use the application password of google as a try.
Another way is just use the url of you google docs to visit certain contents, see http://www.r-bloggers.com/access-google-spreadsheet-directly-in-bash-and-in-r/
Update:
In the source code of getGoogleAuth, the author used an application called 'R-GoogleDocs-0.1', you may apply an new application and get the token. Then I think you could use the token and the api from google to access google docs directly in R. However, such hacks almost mean update/rewrite RGoogleDocs package.

OData error: "A value without a type name was found and no expected type is available." when calling Azure Active Directory Graph API

Let's see if you experts have a clue of what's going on here.
Context
We have a web application running on Azure Web Sites. This WebApp uses OWIN + OpenID Connect to authenticate users against an Azure Active Directory tenant. Also the application uses the Azure AD Graph API to collect some data of the directory.
We based our code on this sample project provided in GitHub: https://github.com/AzureADSamples/WebApp-GraphAPI-DotNet
Issue
The WebApp was working perfectly some hours ago (authenticating to the AD and fetching data from the directory), but then the weirdest thing happened to us. Today we found that we could still authenticate against the AD but the Graph API was throwing errors almost randomly.
We traced the error down to a specific request, when trying to get a specific user by ObjectId in a synchronous way:
Claim claimObject = ClaimsPrincipal.Current.FindFirst(Helper.Constants.ADTenant.ObjectIdClaimType);
string userObjectID = claimObject == null ? string.Empty : claimObject.Value;
ActiveDirectoryClient client = AuthenticationHelper.GetActiveDirectoryClient();
List<IUser> users = client.Users.Where(u => u.ObjectId == userObjectID).ExecuteAsync()
.Result.CurrentPage.ToList();
The thing is the last line throws an exception regarding the OData model:
"A value without a type name was found and no expected type is available. When the model is specified, each value in the payload must have a type which can be either specified in the payload, explicitly by the caller or implicitly inferred from the parent value."
We started slicing the last line of code into pieces as follows:
IReadOnlyQueryableSet<IUser> queryUsers = client.Users.Where(u => u.ObjectId == userObjectID);
IPagedCollection<IUser> pagedUserCollection = queryUsers.ExecuteAsync().Result;
List<IUser> users = pagedUserCollection.CurrentPage.ToList();
And found the exception was throwing in this line:
IPagedCollection<IUser> pagedUserCollection = queryUsers.ExecuteAsync().Result;
Weirdest thing is that this line was executing fine yesterday and today started failing without explanation.
Does anyone know what are we doing wrong? Why did it start failing today?
Remarks
We are using api-version=2013-11-8. We kept the Azure AD Graph API Client Library on version 1.0, as in the sample on GitHub.
Folks,
First of all - many apologies for introducing this problem. The underlying problem is that an entity (User entity in this case) was updated on the service side, with a new collection (AlternativeSignInNamesInfo). Typically adding new entities, properties, collections and complex types should not cause a breaking change for the client library. However due to an issue in ODatalib, unknown collections are not simply ignored.
I totally agree with the sentiment on this, and we absolutely do NOT want to have apps that take a dependency on the Graph Client Library be subject to ANY outages. We are working with the ODatalib team to get this issue rectified, so that this is no longer a problem with our Graph client library moving forward.
In the meantime we are in the process of rolling back our Graph service, so that 2.0.5 should start to work again. Version 2.0.6 should also work - as long as you don't try and post to the new collection on the User object (AlternativeSignInNamesInfo).
UPDATE: The Graph service has been rolled back. I’ve also verified that getting a user through Graph Client Library 2.0.5 AND 2.0.6 both work.
Hope this helps and again sorry for any issues caused here.
I had the same problem just now! I have an application which have been working for a couple of weeks and hasn't been changed. I've got it working by upgrading "Microsoft.Azure.ActiveDirectory.GraphClient" from version 2.0.5 to 2.0.6
Yes upgrading the graph client Nuget package to the latest 2.0.6 fixed this problem. I had a similar panic this morning too. It's an unbelievable fact that Microsoft rolled out a new version of the dll which breaks applications run on previous version!
My team had similar experience. After installing 2.06 our code started working again. Took the entire day with first discovering, fixing, and then testing the solution.

RIAK-CS Unable to create bucket using s3cmd - AccessDenied

I have the following setup: riak 1.4.12, riakcs 1.5.3, stanchion 1.5.0
I am able to list bucket contents, and the authentication works (I get a response when listing or trying to remove a bucket, PUT a file) but get an AccessDenied error when trying to create a bucket.
I found this thread http://riak-users.197444.n3.nabble.com/RIAK-CS-Unable-to-create-bucket-using-s3cmd-AccessDenied-td4032375.html and tried adding signature_v2 = True to .s3cfg with no success, and I've also tried three versions of s3cmd (1.5.0, 1.5.0alpha, 1.0.1) I also tried creating a bucket using the python library boto, which also gives an access denied error.
I'm stumped :( any suggestions on where I should look next would be greatly appreciated! Not sure where there are logs for individual operations against Riak-cs - I've set lager log level to debug and wasn't able to see anything in the logs.
Thanks!
Ambert
I posted the same question to riak-users mailing list, and got an answer!
In my case, I had to set the admin.key and admin.secret in /etc/stanchion/stanchion.conf.
After setting them, s3cmd mb succeeded.

oauth flickr api using httr to retrieve token

I would like to use httr to link up/upload my R image outputs to flickr, but am having difficulty with the initial stages where i need to authenticate myself using OAuth 1.0.
I previously created an app by going to the following link http://www.flickr.com/services/apps/create/apply/
and then got a secret and key string for that app...
I then used it in the httr package function to get a token but to no avail. I have been trying to use the provided documentation on this link http://www.flickr.com/services/api/auth.oauth.html to help out but, I am struggling...
The following is the code I used.
flickr.app <- oauth_app("flickr",key="xxxxxx", secret="xxxxxxxx")
flickr.urls <- oauth_endpoint(request="http://www.flickr.com/services/oauth/request_token",
authorize="http://www.flickr.com/services/oauth/authorize",
access="http://www.flickr.com/services/oauth/access_token")
flickr.token <- oauth1.0_token(flickr.urls,flickr.app)
from which i get the error message
Error: http client error (400)
Not too sure where to go from here...any help would be much appreciated.
N.B. Also I recognise that due to the nature of setting up api links, that there are secrets , api-keys, logins and passwords that need to be kept secret etc, but it does not take long to set up a dummy flickr account from www.flickr.com , to be able to reproduce the problem...in my opinion...perhaps others could try setting one up and letting me know if they got similar issues, and potential methods to work around the situation?
I have never used the httr library, but I recently (as of yesterday) just finished writing from scratch Objective-C code to access Flickr. The biggest pain point for me was figuring out how to correctly encode the signature. I don't know the httr library well enough, but if I had to guess my guess would be that it is not encoding the signature properly.
If you read through this: http://www.flickr.com/services/api/auth.oauth.html
You will find very detailed instructions on how to authorize with Flickr - it was useful to me because I wrote the code in Objective C from scratch. Might be less useful to you unless you are able to debug through the httr source and figure out if it is doing things exactly as Flickr expects.

Resources