• Welcome to KonaKart Community Forum. Please login or sign up.
 

How to get DigitalDownload Link?

Started by ReLLiK75, December 02, 2008, 09:38:48 pm

Previous topic - Next topic

ReLLiK75

I'm trying to figure out how KK serves up the url for DigitalDownloads.  I'm using only using the SOAP API to communicate with KonaKart, which includes the dynamic creation of products and adding basket items, but it looks like there is no API call that will return the full link for a DigitalDownload.  I know the DigitalDownload object contains a Product object which includes the filepath, if the product is a DigitalDownload, but the filepath isn't going to help any in a distributed environment, where KK is residing on a different server than my SOAP application--security restrictions won't allow access to the file via filepath.

Taking a look at the some of the java classes included with KK, specifically DigitalDownloadAction, it seems that the link button references this bit of java code that decides whether or not to send the file to end user. 

Wouldn't it make more sense and be more secure if getDigitalDownloads or some new API call was available that returned an encrypted URL that directly referenced the file to be downloaded?

If there is no way of getting this full link, is there some way I replicate what KK is doing on the My Account page by sending a request to "http://<some server>:8780/konakart/DigitalDownload.do?prodId=xx".  I know I can't do this directly because the session credentials will not be the same between my Flex app and simply making the above http request.  I could send the request to my own FileDownload.aspx and pass in the filename from the Product object, but that pretty much by-passes all KK security.

Any help would be greatly appreciated!
Thanks!
Wayne

julie

You can take a look at DigitalDownloadAction.java to see how we download digital downloads. You have the source code of all of the action classes.

ReLLiK75

Hi Julie...

Yep...already did that.  That class is what concerns me since it is responsible for serving up the download link to the user.  Without all the checks and balances in that class, the download is basically unsecure.  I ended up putting together a aspx page that duplicates the functionality in the DigitalDownloadAction.java file.  My Flex UI makes the SOAP API call to get all digitalDownloads for the customer and then hands the filepath over to my FileDownload.aspx page which simply serves up the file so the user can save to disk.  The loophole is that I really don't have to call insertDigitalDownload and that I can simply check to see if my product has a filepath != null and then send that value right to my FileDownload.aspx

What would be a more efficient and secure way of handling this (here's a suggestion for the next release of KK) is that you develop an API called getDigitalDownloadLink(int productID) which returns an encrypted URL pointing to the digital download.  Perhaps you make it so that all digital downloads are stored as Blobs in the DB to further enhance security and remove the need to specify security permissions at the filesystem level.

Just a suggestion...

Thanks for the response!
Wayne

julie

QuoteWhat would be a more efficient and secure way of handling this (here's a suggestion for the next release of KK) is that you develop an API called getDigitalDownloadLink(int productID) which returns an encrypted URL pointing to the digital download.  Perhaps you make it so that all digital downloads are stored as Blobs in the DB to further enhance security and remove the need to specify security permissions at the filesystem level.


But we need to manage the number of times a product has been downloaded and disable downloads after certain periods of time. Maybe a JSP that can be passed a sessionId and productId could be an alternative idea ?

ReLLiK75

Hi Julie..

A jsp and the API would actually be the best way.  That way, you can track the number of downloads, but you can have the API manage whether the link even gets returned at all.  If the download is expired, simply don't return the link or throw an exception.

Wayne 

julie

My idea was that the JSP returns the file directly as its output, rather than it returning a link. In this way a customer can edit the JSP to get the file from wherever he has it stored (file system, blob, under the matress etc.) and then write out the bytes in the JSP in a similar way to DigitalDownloadAction.