New Version of Tweetinvi Creating some issues - twitter-oauth

before update am using tweetinvi 0.9.07 and it works fine when I update it with the latest version it will generate several errors which are in snapshots

Tweetinvi credentials has changed in version 0.9.9.x.
You can find the documentation regarding this here.
TwitterCredentials.SetCredentials has changed to Auth.SetUserCredentials.
TwitterCredentials.ExecuteOperationWithCredentials has changed to Auth.ExecuteOperationWithCredentials.
Also please note that Auth.ExecuteOperationWithCredentials uses the credentials defined by creds. You therefore do not need to call Auth.SetUserCredentials inside a lambda of ExecuteOperationWithCredentials.
Finally please note that you can now create credentials via the new TwitterCredentials(...).

Related

firebase_functions/unauthenticated UNAUTHENTICATED Flutter firebase functions admin [duplicate]

Recently I added a couple of new callable firebase cloud functions to my mobile app. The thins is, once I deployed and tested my functions I was not able to invoke them failing with an UNAUTHENTICATED error. I re-deployed all my functions and still, the old ones can be invoked while the new one failed with UNAUTHENTICATED. I did some research and people were talking about the version of the Node. I upgraded the Node version but it did not work out. I upgraded the firebase-functions version and the firebase-admin version. No luck.
I tried to browse to the URL of one of the older callable cloud functions that I have deployed before and it was ok. Then I tried to browse to a newly deployed https callable firebase cloud function. I saw this message in my browser:
Your client does not have permission to get URL /function_name from this server.
Any ideas what is going on here?
Thanks
Ok, here is what I found.
According to this page: https://cloud.google.com/functions/docs/securing/managing-access-iam#allowing_unauthenticated_function_invocation
As of January 15, 2020, HTTP functions require authentication by
default. You can specify whether a function allows unauthenticated
invocation at or after deployment.
Here is what you do:
1- Browse to the link above
2- Find "Viewing users" section and click on the "Go to Google Cloud Console" button.
3- On the screen that opens, you will see a list of your deployed cloud functions.
Select the one that is throwing the UNAUTHENTICATED error.
Click the Add Member button that appears on the right pane.
4- Select Cloud Functions Invoker role
5- Type allusers inside the "New Members" box. Select allUsers or allAuthenticatedUsers (Try with both to see which one works for you)
6- Hit "Save"
You should be able to invoke your firebase https callable cloud function now, and the UNAUTHENTICATED error should be gone.
I was having the same problem and what worked for me, was as simple as changing the function's name in the file (and of course where it was called) and redeploying it, which automatically deleted the first one.
EDIT #1: I've just had the same problem again and this time, I didn't rename the function. I only deleted the function manually inside firebase and then I redeployed it. It also works.
EDIT #2: Once again I had the same problem. However, this time I couldn't fix it with the alternatives above. I had upgraded my firebase-tools and something on this new version (10.3.1) was conflicting. Until I figure out what is the problem, I just downgraded firebase-tools (following this: https://stackoverflow.com/a/57262942/14608654) to version 10.2.2 and the error vanished.
in my case, I write wrong function name in my Flutter app
final callable = _functions.httpsCallable('wrong function name in here');

VSTS Extension - Token authentication error

My team and I are working on creating a VSTS extension that will work with VSTS/Azure DevOps in the cloud, but the following 500 error is being thrown when trying to do a REST request:
HostAuthorizationNotFound
Microsoft.VisualStudio.Services.DelegatedAuthorization.SessionTokenCreateException
Here's the code:
// Get an instance of the client
var client = RestClient.getClient();
client.getWorkItem(10343, ["System.Title"]).then(
function(workItem) {
console.log(JSON.stringify(workItem))
},
function () {console.log("test")}
);
Uninstalling and reinstalling the extension has no effect, which seems to be the solution for others who have encountered this problem, and the extension scope was updated to include work items.
Additionally, the personal access token generated for my account works with the VSTS CLI. I'm able to create and query for work items with no issues there.
The Microsoft documentations mentions manual token creation for programs such as C# console apps, but my impression is that this should not be needed when working with an extension.
Is there something token related that needs to be explicitly declared in code?
The solution ended up being the same as what others have posted about: uninstalling and reinstalling the extension. In this case this was something that we tried initially but did not do entirely correctly -- the reinstallation did not take full effect since all the steps weren't followed (an admin also needed to approve the republishing of the extension).
So if you get this error, rest assured that uninstalling and reinstalling should do the trick!
See the following link for more details: https://learn.microsoft.com/en-us/azure/devops/extend/get-started/node?view=vsts#install-your-extension

How can I overwrite an unmanaged solution when using deploying a CRM package?

Using a powershell script to deploy a CRM Package works well, but I am running into some unexpected behavior.
The package has 1 unmanaged solution that it uploads. It works perfectly if the solution does not exist on the target CRM organization. However, if the solution does already exist on the organization and I try to deploy it again with some changes, it will not work. The changes are not uploaded and I do not get any errors.
If I change the version number in the solution (from 0.0.1 to 0.0.2, for example) then uploading it works as expected.
I would rather not change the version every time though, and since manually uploading an unmanaged solution with the same version number works perfectly I would expect the script to be able to do it as well.
I tried using the CRM Package Deployer method of importing a package to see if it would work as I expect or if it would show any error messages.
It's messages show:
Skipping solution MySolution. Version 0.0.2 of the solution is already loaded.
So it appears that if a solution with the same name and version number exists in the organization then it will be skipped entirely. This is sort of unfortunate.
It seems I'll have to implement a workaround. I see two options:
The DeployPackage script deletes the solution in the target CRM organization (if it exists) before attempting to upload.
My ExportSolution script changes the version number every time it runs.

How do I disable automatic updates for Azure VM extensions?

We have a few VMs in Azure and we rely on the PowerShell DSC extension to deploy our code to the machines. I want to make sure that this extension is not updated automatically so that our code that uses functionality from this extension don't break without we knowing about it first.
The problem is that we have some deployment scripts that read the extension's status codes/messages and do custom logic based on them. When the extension was updated from 1.4.0.0 (which is the version that the plugin was on when we first started using it) to the version 1.5.0.0, some of the status messages changed and our script stopped working. This completely broke our deployment process and we had to do an emergency update on our scripts to be compatible with v1.5. Now that version 1.7.0.0 was released the same exact problem happened again. Some new status codes were added and I had to update our scripts or we would not have a working deployment pipeline.
Is it possible to specify a manual update process for these extensions? Their installation and update seem to be completely automated. Ideally, I'd like to be able to update them on a case by case basis after testing our scripts against the newer versions first, so that our deployment process is not halted because of that. Bonus points for anyone who manages to find up to date documentation or some kind of release notes document for this extension in particular, as I could find none... I was just surprised to see that version 1.7 was installed today when I got an error from our script, and was lucky to know exactly where to look for the status changes.
The default behavior for the DSC extension handler is to update to the latest version. If you want to tie yourself down to a specific version, then you can do so with the following cmdlet (currently there is no provision from the UI)
Set-AzureVMDscExtension -Version
Please note that we are also try to ensure updates do not cause issues. We are not there yet but we would certainly like to get there so everyone is automatically updated.

problems after Cloud SQL Administration API update

First, after I updated the Cloud SQL Admin API via Eclipse, I noticed that some of my classes broke. Apparently the API had changed.
Specifically, methods in ExportContext had changed; setDatabase() was no longer present and had been replaced by setDatabases() and setTable() had been replaced by setSqlExportOptions().
BUT, the problem is, after updating my code to the new API, it won't run.
New Code:
ExportContext exportContext = new ExportContext()
.setFileType("SQL")
.setDatabases( Arrays.asList(srcDatabase) )
.setSqlExportOptions( new SqlExportOptions().setTables( new ArrayList<String>(tableNames) ) )
.setUri(dumpUri);
Here is the exception:
(com.google.api.services.sqladmin.model.ExportContext.setFileType(Ljava/lang/String;)Lcom/google/api/services/sqladmin/model/ExportContext;)
java.lang.NoSuchMethodError: com.google.api.services.sqladmin.model.ExportContext.setFileType(Ljava/lang/String;)Lcom/google/api/services/sqladmin/model/ExportContext;
How can i fix this?
The new version of the Cloud SQL Admin API, v1beta4, was recently released and it includes a few changes like the ones you are saying. For example setSqlExportOptions needs to be set for exporting data in SQL format.
The old version, v1beta3 is still available. My guess is that you never specified an API version and eclipse automatically generated the client code for the latest version. Make sure you specify which version you want to use.