From: Wolfgang Enzinger on 14 Mar 2010 06:12 On Fri, 12 Mar 2010 15:39:43 -0500, mayayana wrote: > For registering a file type, look in the Registry. Ready-to-use routines for this task can be found here: Associate a file type http://www.enzinger.net/en/FileAsso.html
From: GS on 14 Mar 2010 16:37 Webbiz has brought this to us : > On Sat, 13 Mar 2010 16:40:05 -0500, GS <GS(a)discussions.microsoft.com> > wrote: > >> Webbiz explained : >>> On Sat, 13 Mar 2010 12:57:52 -0500, GS <GS(a)discussions.microsoft.com> >>> wrote: >>> >>>>> I would love to have the application download this file from the >>>>> website automatically. It's easy to do. But I don't know how to >>>>> restrict non-clients who have my app from also getting the file. >>>>> Clients pay for this information. Non-clients do not. >>>>> >>>>> If I can find a solution to this part I would LOVE to do it. >>>>> >>>>> Thanks. >>>>> >>>>> Webbiz >>>> >>>> Is this app licensed? If so, could you not include whether this is >>>> available to your client in the license profile? Obviously, this >>>> requires your licensing methodology to support this and so is why I >>>> suggest going this route. This way, automatic download can be available >>>> from your app but is only allowed to apps with the correct feature >>>> enabled in the license profile. >>>> >>>> I.E.: If LicenseProfile.HasDownloadService Then DownloadWeeklyUpdate >>>> >>>> HTH >>>> Garry >>>> >>> >>> >>> My app is licensed. But here is the problem. >>> >>> Say a client comes along and subscribes to my services. This client >>> also purchases my app. She gets a license to use the app and also >>> access to the file for download. >>> >>> Later, however, she discontinues the services but wishes to continue >>> using the app. That's fine, she paid for it. However, the app is still >>> licensed to her and so she'd still have access to the file for >>> download although she no longer pays for that. That would be >>> unacceptable. >>> >>> The app is licensed indefinitely and does not expire unless the user >>> moves it to another computer or does a major change to the system (ie. >>> memory, hard drive, mb, etc.). Then the user simply visits the site >>> and fills out the form there for a new registration key and gets it >>> via email. >>> >>> I've been using this approach for 10 years successfully. >>> >>> So as you can see, I have no facility to prevent the indefinite >>> downloading of my file unless I periodically change its name and >>> release periodic updates to the app that notes this new filename. >>> Meanwhile, between updates the user gets my work without paying for >>> it. >>> >>> So for now, users who pay for the work must access the site with their >>> username and password and then click on the link to install the weekly >>> file that way. >>> >>> Webbiz >> >> I do exactly the same thing with my apps, whereby users who "subscribe" >> for Upgrade Assurance Protection can receive app upgrades for free >> along with 24/7 user support. This (UAP) is renewable annually so that >> users may opt out if they don't want it any longer. My apps manage this >> by evaluating the "HasUAP" property of the license profile to verify >> that the subscription has not expired. This is determined by evaluating >> the HasUAP property "value" against the current date, meaning THE >> property VALUE is the expiry date of the subscription. For example, if >> the license profile contains a future date (i.e.: HasUAP=10/24/2010) >> then the feature is enabled. I actually have a dedicated field in the >> license profile for this feature so it can be read directly, but it >> could also be implemented in other ways like using a property=value >> pair as shown here. >> >> This puts the choice of continuing the service entirely in the hands of >> the user. My apps notify users on startup 30 days before this feature >> expires. This happens only once so as not to annoy them every time they >> run the app. It also notifies once when expired. >> >> >> <<I would love to have the application download this file from the >> website automatically. It's easy to do. But I don't know how to >> restrict non-clients who have my app from also getting the file.>> >> It appears as though you are interested in keeping things 'low >> maintenance' for yourself and so is the reason I'm suggesting this >> approach. You only have to issue the license key as you normally would. >> In the case of a new subscriber, you simply issue an upgraded license >> key once you've been paid. Your apps can manage it all automatically >> because the process is built-in. You could manage the users however you >> like (i.e.: weekly subscription, monthly, yearly, fixed term, etc) by >> inserting the expiry date in the license profile. > > > I still don't see how this would work with what I'm need to do. > Subscribers do not have expiration dates. When they join, it is an > opened ended subscription much like joining the gym. As long as you > make the monthly dues your subscription keeps going. > > At some point, however, someone will cancel the subscription. When > that happens, I have no way of making the user get a new license for > the app that disables the ability to use the download file. > > For what I need to work, I must be able to disable their apps ability > immediately upon cancellation of service. > > Perhaps what I could do is create a file online that serves as a > 'table' of subscribers. It would contain the User name that the > program is licensed to. If the user is in the file table the app will > know where to find and download what it needs. If the client cancels > later, we can edit that table and remove the User name. > > It would be one more thing I would have to do of course, editing this > table for new and leaving clients. But it is one approach. > > :-) > Webbiz I see! So your subscriptions are "on demand" and based on the user paying the monthly fee. My suggestion clearly won't work for that. If you already have a 'login' solution to manage who can access the download file then there's nothing to do. I see that Nobody has a good idea for automating the process from your app, that looks more appropriate. In any case, I assume you always have to keep the website login .htaccess updated accordingly to restrict who can download. Nobody's suggestion also requires maintaining a website access list (or black list) so nothing saved here. But at least your users won't have to physically log onto your site anymore. I'm curious.., -can users login and pay for the download online as a one-time thing? Or do they have to prepay for a given period? -- Garry
From: Webbiz on 15 Mar 2010 00:24 On Sun, 14 Mar 2010 00:44:14 -0500, "Nobody" <nobody(a)nobody.com> wrote: >"Nobody" <nobody(a)nobody.com> wrote in message >news:uC92CAzwKHA.1548(a)TK2MSFTNGP02.phx.gbl... >> You need to make the URL for the file as follows: >> >> mysite.com/getfile.asp?SUBID=123456789 >> >> In the ASP file, which uses VBScript, you check the subscriber ID and use >> If/Then/Else. You can make the ID a very long random number, so guessing >> it would be difficult. > >Below is an ASP script sample. To try it, save it as "test.asp" and upload >it to a Windows based host, then enter the URL like the following: > >mysite.com/getfile.asp?SubID=1234 > >Some of the code came from this site: > >http://www.learnasp.com/freebook/asp/ > >The code below does simple checks. If you want it to check a database, see >"Databases" section in the link above for code samples. If you have a >Unix/Linux host, then you have to use something else, like PHP. Fortunately, >PHP runs on Windows, so you can test the script on a Windows machine, then >upload it to Unix/Linux host without modifications(Except CR/LF conversion >which is handled by most FTP software). See this site for PHP help: > >http://www.php.net > >Here is the ASP file: > ><html> ><head> ><TITLE>Test</TITLE> ></head> ><body> ><% >Option Explicit > >Dim SubID, fs, filename, f, s > >SubID=request.querystring("SubID") > >If SubID = "1234" Or SubID "1235" Then > ' Subscriber is black listed > Response.write "Access denied." >Else > ' Valid subscriber, send the file > > filename=server.mappath("/datafile.txt") > Set fs = CreateObject("Scripting.FileSystemObject") > Set f = fs.OpenTextFile(filename, 1, False) > s=f.readall > response.write s > f.Close > set f=nothing > set fs=nothing >End If >%> ></body> ></html> > > > I use an Apache server. Thanks anyway. :) Webbiz
From: Webbiz on 15 Mar 2010 00:27 On Sun, 14 Mar 2010 16:37:08 -0400, GS <GS(a)discussions.microsoft.com> wrote: >Webbiz has brought this to us : >> On Sat, 13 Mar 2010 16:40:05 -0500, GS <GS(a)discussions.microsoft.com> >> wrote: >> >>> Webbiz explained : >>>> On Sat, 13 Mar 2010 12:57:52 -0500, GS <GS(a)discussions.microsoft.com> >>>> wrote: >>>> >>>>>> I would love to have the application download this file from the >>>>>> website automatically. It's easy to do. But I don't know how to >>>>>> restrict non-clients who have my app from also getting the file. >>>>>> Clients pay for this information. Non-clients do not. >>>>>> >>>>>> If I can find a solution to this part I would LOVE to do it. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> Webbiz >>>>> >>>>> Is this app licensed? If so, could you not include whether this is >>>>> available to your client in the license profile? Obviously, this >>>>> requires your licensing methodology to support this and so is why I >>>>> suggest going this route. This way, automatic download can be available >>>>> from your app but is only allowed to apps with the correct feature >>>>> enabled in the license profile. >>>>> >>>>> I.E.: If LicenseProfile.HasDownloadService Then DownloadWeeklyUpdate >>>>> >>>>> HTH >>>>> Garry >>>>> >>>> >>>> >>>> My app is licensed. But here is the problem. >>>> >>>> Say a client comes along and subscribes to my services. This client >>>> also purchases my app. She gets a license to use the app and also >>>> access to the file for download. >>>> >>>> Later, however, she discontinues the services but wishes to continue >>>> using the app. That's fine, she paid for it. However, the app is still >>>> licensed to her and so she'd still have access to the file for >>>> download although she no longer pays for that. That would be >>>> unacceptable. >>>> >>>> The app is licensed indefinitely and does not expire unless the user >>>> moves it to another computer or does a major change to the system (ie. >>>> memory, hard drive, mb, etc.). Then the user simply visits the site >>>> and fills out the form there for a new registration key and gets it >>>> via email. >>>> >>>> I've been using this approach for 10 years successfully. >>>> >>>> So as you can see, I have no facility to prevent the indefinite >>>> downloading of my file unless I periodically change its name and >>>> release periodic updates to the app that notes this new filename. >>>> Meanwhile, between updates the user gets my work without paying for >>>> it. >>>> >>>> So for now, users who pay for the work must access the site with their >>>> username and password and then click on the link to install the weekly >>>> file that way. >>>> >>>> Webbiz >>> >>> I do exactly the same thing with my apps, whereby users who "subscribe" >>> for Upgrade Assurance Protection can receive app upgrades for free >>> along with 24/7 user support. This (UAP) is renewable annually so that >>> users may opt out if they don't want it any longer. My apps manage this >>> by evaluating the "HasUAP" property of the license profile to verify >>> that the subscription has not expired. This is determined by evaluating >>> the HasUAP property "value" against the current date, meaning THE >>> property VALUE is the expiry date of the subscription. For example, if >>> the license profile contains a future date (i.e.: HasUAP=10/24/2010) >>> then the feature is enabled. I actually have a dedicated field in the >>> license profile for this feature so it can be read directly, but it >>> could also be implemented in other ways like using a property=value >>> pair as shown here. >>> >>> This puts the choice of continuing the service entirely in the hands of >>> the user. My apps notify users on startup 30 days before this feature >>> expires. This happens only once so as not to annoy them every time they >>> run the app. It also notifies once when expired. >>> >>> >>> <<I would love to have the application download this file from the >>> website automatically. It's easy to do. But I don't know how to >>> restrict non-clients who have my app from also getting the file.>> >>> It appears as though you are interested in keeping things 'low >>> maintenance' for yourself and so is the reason I'm suggesting this >>> approach. You only have to issue the license key as you normally would. >>> In the case of a new subscriber, you simply issue an upgraded license >>> key once you've been paid. Your apps can manage it all automatically >>> because the process is built-in. You could manage the users however you >>> like (i.e.: weekly subscription, monthly, yearly, fixed term, etc) by >>> inserting the expiry date in the license profile. >> >> >> I still don't see how this would work with what I'm need to do. >> Subscribers do not have expiration dates. When they join, it is an >> opened ended subscription much like joining the gym. As long as you >> make the monthly dues your subscription keeps going. >> >> At some point, however, someone will cancel the subscription. When >> that happens, I have no way of making the user get a new license for >> the app that disables the ability to use the download file. >> >> For what I need to work, I must be able to disable their apps ability >> immediately upon cancellation of service. >> >> Perhaps what I could do is create a file online that serves as a >> 'table' of subscribers. It would contain the User name that the >> program is licensed to. If the user is in the file table the app will >> know where to find and download what it needs. If the client cancels >> later, we can edit that table and remove the User name. >> >> It would be one more thing I would have to do of course, editing this >> table for new and leaving clients. But it is one approach. >> >> :-) >> Webbiz > >I see! So your subscriptions are "on demand" and based on the user >paying the monthly fee. My suggestion clearly won't work for that. > >If you already have a 'login' solution to manage who can access the >download file then there's nothing to do. > >I see that Nobody has a good idea for automating the process from your >app, that looks more appropriate. In any case, I assume you always have >to keep the website login .htaccess updated accordingly to restrict who >can download. Nobody's suggestion also requires maintaining a website >access list (or black list) so nothing saved here. But at least your >users won't have to physically log onto your site anymore. > >I'm curious.., -can users login and pay for the download online as a >one-time thing? Or do they have to prepay for a given period? It's a membership. Payment is made in advance and due each month. The download is from the Discus forum. So it doesn't use .htaccess. :-) Webbiz
From: Webbiz on 15 Mar 2010 00:27
On Sun, 14 Mar 2010 11:12:05 +0100, Wolfgang Enzinger <usenet200812(a)temporaryforwarding.com> wrote: >On Fri, 12 Mar 2010 15:39:43 -0500, mayayana wrote: > >> For registering a file type, look in the Registry. > >Ready-to-use routines for this task can be found here: > >Associate a file type >http://www.enzinger.net/en/FileAsso.html Thanks! Webbiz |