Of course I’m interested in creating this connector, but I can’t. As I work in a big company, I’m “behind” a proxy server. In Easymorph I only have an error message “Can’t authorize”. Here is the true error caught by fiddler :
What do you think ? Is this proxy authentication to manage ?
@dgudkov It seems that you have to include in the http request the property “UseDefaultCredentials” to “True” : https://docs.microsoft.com/fr-fr/dotnet/framework/configure-apps/file-schema/network/defaultproxy-element-network-settings
Microsoft desktop clients are also using it for big companies with proxy.
Is it possible for us to include it now in EasyMorph.config.xml or in new config file without delivering a new easymorph desktop version ?
You may also have to increase DefaultMaximumErrorResponseLength from 64 to 1024 because SOAP error responses go over the limit.
You can try to modify files
Morph.Launcher.exe.config (located at
C:\Users\<username>\AppData\Local\EasyMorph) and append a new text just
</configSections> tag for
<configuration> tag for
<defaultProxy enabled="True" useDefaultCredentials="True">
What problem are you trying to solve? Do you have any issues with SOAP processing?
It’s working. I can even see the opening popup of new version 4.6 that did not appear before
Now I just have to authorize Easymorph in the Power BI administration and I hope it will be ok.
@ckononenko Can you help a little bit on Easymorph registration in Azure ? I mean now I have a screen requesting admin approval for Easymorph. So I guess we have to register Easymorph in Azure AD. Can you explain how it can be done ?
I understand that first we need to create the Easymorph App, get the client ID that we will put in the Easymorph connector as “App UID”. I don’t exactly know how to set properties there. Then we must give the good privileges for this app and maybe that’s all ?
There are at least two options:
Option A. You can use the built-in EasyMorph App, but your corporate admin should grant access to use this app in your organization.
Short info could be found here https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/grant-admin-consent
Option B. Create your own Application client ID.
A short guide can be found here https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app
You should use
Mobile and desktop applications Platform.
Scopes for the Azure application:
Admin consent may be required for the created application.
Then fill in App UID and tenant in the Power BI connector.
Feel free to ask questions.
Thanks for your quick reply. In our case it will be the second option, more secure I think. I requested the creation of a new application in Azure AD, I’ll let you know if it works.
@ckononenko I worked a little bit more on that topic and I understand in Option B that we can manage delegation through our own registered app. I’m ok with that and we are currently implementing this. It means that easymorph user can identify interactively and the app apply the scopes.
But when I look at the Power BI connector in easymorph I see nothing about the secret (certificate or password) which enables a direct app authentication, so that interactivity is not needed and we would generate Power BI datasets through tasks. Is there any way to achieve this and if not, do you intend to implement secret in next versions ?
Edit : it’s not exactly that. It’s not possible to connect as app only for Power BI. We have to use a “master user” as I understand. It’s called “silent authentication” and this post seems to indicate that user/password can be used to authenticate : https://community.powerbi.com/t5/Developer/REST-API-Silent-Authentication-Token/m-p/156004
It’s using the resource “https://analysis.windows.net/powerbi/api” to get a token with client id, username and password
Do you think you could handle this in the future ?
Could you please describe what issues do you have with an interactive authentication?
It seems it’s possible to do this via a service principal. However, we didn’t try it yet.
Currently this flow is not recommended. Also it doesn’t support for MFA.
I don’t have issue by now, I’m still implementing interactive authentication, not yet tested. I was just wondering how we can do without interactivity, to publish datasets as background jobs, through easymorph tasks. Because it’s one thing we also need.
After performing an interactive authentication you should be able to use the Power BI dataconnector up to 90 days. Both desktop and server sides. Including background tasks. After that (or if the password have been changed) you will need to reauthenticate dataconnector once again.
Ok new issue now. We have this error message :
AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application: ‘38f037c6-07a8-44b5-9700-57fc1eeec7f2’.
For mobile and desktop app, Microsoft recommends to configure redirect uri as “https://login.microsoftonline.com/common/oauth2/nativeclient” but it seems Easymorph is not requesting the same. Do you know what redirect uri I have to set ?
Currently EasyMorph uses
urn:ietf:wg:oauth:2.0:oob as a default redirect uri for the Power BI.
Thanks, I try to do that but as I can read, the recommended uri is no more the one you are using, it’s the one I’ve posted above. See https://docs.microsoft.com/fr-fr/azure/active-directory/develop/scenario-desktop-app-registration
It’s finally working great ! Wow what a long way to get there. I understand that everything needs to be text, not integer for example. I was a bit surprised, is it intended ? I also note that connector must be editable to authorize. Usually the connectors provided to our users through the server are read-only, then it will have to be embedded I guess.
Well that’s a major step for us thanks for your patience !
Edit : forget about the text thing, it’s just my dataset which has numbers in a text column, it’s ok !
Noted. Thank you.
EasyMorph should support for all Power BI data types. See https://docs.microsoft.com/en-us/power-bi/developer/automation/api-dataset-properties#data-type-restrictions
Export to Power BI action prevalidates entire dataset before upload.
Pay attention, that
Power BI Push datasets api has some limitations and works in append mode. So, if you want to replace all rows, you need to remove existing data.
Creating any new data connector requires a write permission. After creating a data connector, you could change the Server Space data connectors security settings to prevent further modifications (read-only access). However, I might have misunderstood you. Would you describe an expected behavior?
What I mean is that to renew the token (if you change password of after 90 days for example), you need to click on the authorize button inside the connector, so you need to get access to the connector, which is not possible if the connector is read-only. So in my vision, Power BI connector is not compatible with read-only mode. The best might be to embed it.
Yes I noticed the append mode, so I’m using the other power bi action you provide to clear rows before
Just a couple of ideas on how to make a repository read-only for users, but read-write for admins:
Set up a write password for the connector
In this case only those who know the password will be able to re-authorize or edit the connector.
Shadow admin space
Create a “shadow” space that is only accessible for admins. Configure the space to use the same repository, but enable full access to the repository.
After thought I think there’s a difficulty here : the token of the user is embedded. If connector is embedded in the project, the token is also (even if encrypted I guess). If connector is shared through repo.sqlite, I think the token is in the repo. There is a big security issue here : if someone else than you is using the same connector than you, and you were already authenticated through this connector, he can get your own token and take your own identity. In that case I think this connector can not be shared at all, unless you always remember to reset authorization before you share. Is it right ?
It’s something to know and of course it’s a big security matter.
A token is not the same as identity. A token is linked to an OAuth application, which in turn has specific scopes. Therefore, a token can be viewed as an API key with a certain permission scope. A token can’t be used for another OAuth application, or for a scope that wasn’t explicitly permitted.
Also, when a Power BI user, for whom a token was issued, changes the account password, all previously issued tokens are immediately invalidated and become useless.
As with any other connector, sharing a Power BI (or any OAuth connector) represents a risk, because a connector is basically a set of credentials. Resetting authorization can be required before copying. But again, it’s not different from any other connector.