Logging into WAS application from Alpha Desktop

[Rick Gerlach]

I need to allow my A5V8 desktop application to upload files to a complementary WAS webapp that imports data from the desktop app for use on the web.

I don't want the data to be uploaded to a world-writable folder. Ideally I'd like the desktop application to log into the web app for the user, then upload the file to a location only available to an authenticated web application user.

I realize I could use FTP for this, but I'm not keen on embedding FTP login info in my code.

So, question 1: Is it possible to craft a URL to log into a WAS login dialog, like

http://mysite.com?userid=me?password=mypassword

Is this the best way to login to the web app?

Second, short of sending keystrokes to a browser window with a file upload dialog, can anyone think of a way to upload to a folder that's not world-accessible?

Third, if I am able to upload to the webapp programmatically *without* using a file upload dialog, will I have to use something like FolderWatch on the server to look for files to import?

Fourth, am I overthinking this? Can I just upload the file to a world-accessible folder and use something like FolderWatch to move the files to a secure location when the server spots it? If I do that, how do I notify the server that the upload is complete?

Thanks for any help.

[Peter.Greulich]

Re: Logging into WAS application from Alpha Desktop

Not sure what you are asking. If you want to share your desktop app data on the web using the WAS, you don't need to "upload" data files anywhere. As long as you implement security on the WAS, no one get at your data. Period. Just because the WAS is on the web, doesn't mean that the data is accessable to those who shouldn't be able to get at it. They can't - as long as you implement standard built-in WAS security.

[Rick Gerlach]

Re: Logging into WAS application from Alpha Desktop

Yeah, sorry, I wasn't too clear in my initial post, I was still trying to figure out how the WAS security deals with files.

I don't want the desktop app to publish the data to the webapp, I'm talking about a desktop runtime app that exports data as a zip file to be imported on the server.

I want the desktop app to automatically upload that zip file to the webapp, and have the server extract the files, import them into the webapp dbf files, and do it all with as little user intervention as possible.

How can I do that?

The two ways I *know* I can do it are 1) by having the user login to the webapp and use a file upload dialog. This is not very automated.

2) use a script to FTP the files to the webserver, then maybe have the desktop application invoke a page that starts the processing, or alternately have the server run Folderwatch.

#2 is the best method I can think of, I was just wondering if anyone else has a better idea.

[Peter.Greulich]

Re: Logging into WAS application from Alpha Desktop

Again, I don't know why you want to do it that way, but I suppose it is possible. The "standard" way is like this:

Say your desktop app has tables: A,B, C, D & E. You only want the web to show certain records of Table B. Assuming that your desktop files are on the server anyway, you just cionfigure the web app to filter table B and only allow access to those records of that table to legal users that have a password.

BUT, if you need to do it the way you described, then that is much more difficult. Do a search in this and WAS-7 forum on uploading files.

[Rick Gerlach]

Re: Logging into WAS application from Alpha Desktop

I don't think I'm communicating clearly. I already have web security implemented. Users of the web app can only see their records, etc. Got that all worked out.

I have hundreds of desktop users that will be uploading data to this web application. They will be constantly updating their data and uploading it daily. I want this to be a 1 click process for the user if possible.

The web app will delete their old data from the web app tables, take their uploaded data file and import it so it's available to their customers on the web.

Clearer picture?

I have searched the forum and I don't see another method other than the ones I outlined in my previous post. I was just hoping someone might see a method I overlooked.

[Steve Wood]

Re: Logging into WAS application from Alpha Desktop

Yes, you can create a URL like you suggest that automatically logs in to the web application. The function is a5ws_login_user() and its not in the Hlelp document. But it has bubble help if you type that function into code.

You would create an A5W page that expects a URL with userid and password (at least) as parameters and then use the function to automaticlaly log the person in.

Use at your own risk.

[Rick Gerlach]

Re: Logging into WAS application from Alpha Desktop

Thank you Steve. I've been avidly reading your posts here on the board and they've saved me a lot of time in figuring out how to do things with WAS.

I've settled on using FTP to upload the files, then having the desktop A5 app open a URL that will cause file processing to take place.

My main concern is only allowing authorized users to run the processing on that page, so I have a choice of creating an alternate method of authentication, or using the WAS built-in security, so that function will make my life easier.

I had thought about encoding the URL with an MD5 string, but it would require the server to have an MD5 hash of the user's password, and I can't retrieve that from the WAS Web Security.

I think what I will do is encrypt the login info into the uploaded file, then have the server unzip the file, decrypt the login info and proceed with processing if the login is successful.

That way I can use the A5 encryption functions with worrying about URL encoding the string, and I don't have to worry about someone retrieving the user's info from the browser history.

At worst, if someone knows the URL of the processing page and the upload file naming convention AND has the FTP login info, they could upload a zip file with whatever they wanted, and then cause the server to unzip the encrypted login file, but they cannot force processing to continue unless that file contains accurate login info that is encrypted with the proper key.

Can anyone poke holes in my thinking from a security standpoint?

[aschone]

Re: Logging into WAS application from Alpha Desktop

Sorry for poking my head in on this conversation but thought I would throw a couple of ideas out there.

Seems to me like this is being make more difficult than need be. I am not seeing a reason behind having the username/password encrypted in the file to be uploaded.

You already have created an FTP server, create individual accounts / folders for each of the users that will be uploading via FTP. Secure the folders so only the approved user is able to access the folder. Create a table in the database to store the username / password of the FTP users. Using filters you can limit the display of the data to the record the only the current user should see.
(I am using Secure FTP 2.5 from www.glub.com, the client side has the capability to encrypt the password for use in a script. I think this would be an easy to use feature to encrypt the password in the table)

On the server side, watch the folders for new files, or batch the process and wait until the end of the day and then process all files in the FTP folders.

Basically by each user having their own folder / password / security you don't have to worry about another user seeing data they shouldn't be seeing. Also you will not have to write your own security implementation but use the one provided by the FTP server.

Forgive me if I have strayed to far offtopic on this one.

-Andy

[Rick Gerlach]

Re: Logging into WAS application from Alpha Desktop

Andy,

Thanks for your ideas. That's a viable approach, but for me, it comes down to a question of the overhead of managing the FTP folders/accounts. I will have hundreds of users accessing this. I do not want to have to create/manage hundreds of FTP accounts in addition to the accounts for WAS.

It comes down to how you indicate to the server who the data belongs to. Your method relies on the server checking hundreds of folders for file changes. The assumption on the server side is that only a properly authenticated FTP user has access to that folder.

Seems simpler for me to have a single upload folder with write only access. By embedding the user's login info in the file, the server will know which user's data this is and that it is a valid upload from my desktop app without me having the overhead of duplicating all my WAS accounts in the FTP server and managing a bunch of folders. File naming is not an issue, as it will contain an account number unique to the user.

If someone figures out the FTP login info, the worst they can do is upload a file to the folder or even overwrite a valid upload if they time it just right.

Even if they are able to counterfeit the file the server is expecting to see, without the properly encrypted WAS login info, the server won't do anything with it.

The question of who gets to initiate processing is what I'm still on the fence about. If I set the processing page security to Always Denied, then only WAS could load it via something like FolderWatch.

I like the immediacy of allowing the user to tell the server to deal with their upload, and this will work in a situation where my web app may be hosted where the provider will not allow Folderwatch.