It’s not a proxy, it’s a Floxy! A way to display SharePoint PDFs in PowerApps

Send to Kindle

Hiya

I will say up-front that I used to be a security guy, so what I am about to share with you makes part of me feel dirty. With that said, I think this method is worth sharing because I get to call it a Floxy, and we all know that coming up with cool names trumps all other considerations!.

So what am I talking about? Let’s use an example…

In PowerApps, one can display a gallery of PDFs quite easily. Just drop it onto a screen and feed it a URL by setting the Document property. Here is an example PDF from a journal article I wrote with Kailash Awati…

image  image

Okay so that was easy… but what happens if you put these images inside SharePoint? In the next screen, I have saved the same PDFs as shown above to a SharePoint document library and entered its link into the PDF control in PowerApps. Now look at what happens…

image

So what’s going on here?

In a nutshell, when PowerApps tries to access the SharePoint URL, it does so anonymously. Now that’s all well and dandy on a public URL like the first example, but isn’t going to do much good with SharePoint, which requires authentication. It’s a pity really, since there are many use-cases where it would be wonderful to browse SharePoint libraries for PDFs. Think of remote workers calling up drawings or schematics as an example.

So is there a (clever) workaround? Sure is!

Flow to the rescue…

Microsoft flow happens to have a SharePoint action called “Get file content using path”.

image

Basically you feed this action two things: 1) a site collection and 2) the path to a file residing in a document library. In return for your efforts flow will bring back the content of that file. Since, all SharePoint flow actions are authenticated, if we can find a way to pass a URL from PowerApps to flow, and have flow return the file content back to PowerApps we could in effect, get around this authentication issue.

Turns out this is pretty easy. Here are the steps…

1. Create a new blank flow using the Request trigger. We are going to make this flow into a webservice and PowerApps is going to call it, passing the reference to the required file.

image

Now the important but is to click “Show Advanced Options” and to change the method to a GET.

image

2. Add a compose action using the expression ‘trigger()[‘outputs’][‘queries’][‘itemurl’]’ (no quotes). What this does is tell flow to look for a parameter called itemURL from the workflow trigger (step 1). Specifically, we are telling it to look for itemurl in the query string from the HTTP request made by PowerApps.

image

While you are there, rename the action to “Get PDF Path”.

image

3. Add a SharePoint – Get File Content Using Path action. Specify the site collection you want to work with and then set the “File Path” parameter to be the output of step 2 (Get PDF path).

image

4. Add a request – response action. In the “Body” parameter, add the File Content from step 3.

image

Now create this flow and re-open it. The Request trigger will have a URL generated. Click the icon to copy this URL to clipboard. We are going to need it in PowerApps.

image

Right you are done with Flow. Now go back to PowerApps and change the Document property for the PDF viewer to the URL you just copied, but make one change, namely adding an itemurl parameter. eg:

  • from: http://bigflowurl
  • to http://bigflowurl&itemurl=/Shared Documents/<name of your PDF file>

Going back to my original PDF it becomes:

“https://[flow host].[location].logic.azure.com:443/workflows/[workflow ID]/triggers/manual/paths/invoke?api-version=2016-06-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=[sig]&itemurl=/shared documents/towards-a-holding-environment-final.pdf

So let’s test in PowerApps… wohoo!

image

Conclusion and caution…

Okay so we were able to solve a problem fairly easily by using Flow to perform the authenticated connection to PowerApps. In fact, with a little imagination you can extend this idea out further like my video below where I make a document library/pdf browser.

As I mention in the video, Flow has in effect become a proxy – or a floxy Smile. But the issue is now you have a URL that has the ability to access items in the site collection anonymously and potentially expose things you do not want to.  After all, you could give that URL to anybody and if they change the file specified, then you are exposed.

So my strong suggestion is to think carefully about this and take steps to mitigate any risk. For example, add some checks into your flow if you only have one document library that you want to be able to pull files from. Perhaps leverage the differences in the HTTP request between a browser and PowerApps and check the trigger headers (as an example the “User-Agent” for PowerApps is different to what a browser will report). After all, you have to be authenticated to use PowerApps so the real risk is hitting the flow URL from non-PowerApps sources.

Now one other consideration with this… it will run a lot of Flows, so keep an eye on your monthly flow run limits. Also really importantly, things move fast in this space, so the gap addressed by this method may go away really soon. For example: you do not need to use a floxy with images anymore.

Like I said at the start, there is a part of me that feels a little dirty about this method because it allows an unauthenticated URL access to authenticated content, but then again with appropriate controls it should be ok.

Hope this helps you and thanks for reading…

 

Paul Culmsee

 Digg  Facebook  StumbleUpon  Technorati  Deli.cio.us  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle

A lesser-known, but really important update to PowerApps

Send to Kindle

This week, the PowerApps team released a great update to PowerApps that should make any InfoPath person very happy. PowerApps now supports the use of rules that allow you to easily modify the behaviour of an app based on criteria that you specify. Previously this had to be done using variables and was one of those aspects to PowerApps that felt “developery”.

This is a great new feature and I will record some videos on this in the not-too-distant future…

But there is another update to PowerApps that seems to have slipped under the radar. This one is really huge for anybody who wants to leverage rich media in SharePoint…Up until now, there was a problem with authenticated connections when using controls like the Image or PDF controls. Consider this list:

image

In this example, we have a Title column and a hyperlink column called CatPhoto. Up until recently, if you were to try and display this content in PowerApps, only anonymous URL’s would work. In the example above, the first 3 cat photos are in a SharePoint document library called Pics, and the resulting URL is an internal one (eg: https://culmsee.sharepoint.com/Pics/cat1.jpg). The 4th image in the list above is Ralph, who apart from being a dog, is an external image – eg: https://i.ytimg.com/vi/SfLV8hD7zX4/maxresdefault.jpg.

Previously, if you pulled this list into PowerApps and tried to display this in a gallery, you would only see Ralph. PowerApps would try and access the SharePoint URL’s without credentials and fail.

<Edit: If your original SharePoint column storing the URL is set to display URL and not picture, the issue remains!! If you are affected by this you can try my Floxy method>

But now if we pull the above list into PowerApps we now have awesomeness!!!

1. Add a SharePoint data source and connect to the list of cats

image

2. Add a horizontal gallery and set the data source to SharePoint.

image  image

3. Sit back and enjoy the awesomeness!

image

Now how did the PowerApps team pull this off? The easiest way to tell is to add a label to the gallery and have a look at the CatPhoto column. Previously it was the URL of the image as it is stored in SharePoint, but now it is very different…

Looking at the above image, Ralph’s URL still looks normal, but the SharePoint URL’s have been rewritten. Passing through a decoder and we can start to ascertain what’s going on..

appres://datasources/Cats/rows/1/reference/https://australia-001.azure-apim.net/apim/sharepointonline/[snip a GUID]/datasets/https://culmsee.sharepoint.com/GetFileContentByPath?path=/Pics/cat1.jpg

The closest thing to this URL format I have been before in PowerApps is when you upload media. It also uses the appres:// URL prefix too.

My guess of the above is:

Application Resources (appres://) –> Data Source (datasources/Cats/Rows/1) –> Datasource webservice endpoint (reference/https://australia-001.azure-apim.net/apim/sharepointonline/[snip a GUID) –> data source parameters (https://culmsee.sharepoint.com/GetFileContentByPath?path=/Pics/cat1.jpg).

Now I experimented by manually changing the item in the path parameter for the GetFileContentByPath call. This worked fine… I was able to specify a PDF in the Shared Documents library and set that as the content source for the PDF control as shown below…

image

Conclusion

This is a brilliant enhancement to PowerApps and will open up many use-cases, given that SharePoint is the de-facto content store for most organisations. Furthermore, if you utilise my technique of using Flow to facilitate photo uploads into SharePoint, now we have closed the loop. We can take and upload photos, and subsequently browse, tag or mark them up.

Watch this space for some demo apps that take advantage of this new functionality!

Paul

 Digg  Facebook  StumbleUpon  Technorati  Deli.cio.us  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle