I need to create an ASP page (classic, not ASP.NET) which runs remote shell scripts on a UNIX server, then captures the output into variables in VBScript within the page itself.
I have never done ASP or VBScipt before. I have tried to google this stuff, but all I find are references to remote server side scripting, nothing concrete.
I could really use:
An elementary example of how this could be done.
Any other better alternatives to achieve this in a secure manner.
Are there any freeware/open source alternatives to these libraries?
Any examples?
If the shell scripts are normally run on a telnet session then you could screen scrape and parse the responses. There are commercial COM components out there such as the Dart telnet library: http://www.dart.com/pttel.aspx that would let you do this.
Either that or you could roll your own using AspSock http://www.15seconds.com/component/pg000300.htm
#Pascal, sadly I'm not aware of any F/OSS alternatives. We usually just buy in these types of libraries provided that they're not hugely expensive, and more often than not the cost is built into the customer's overall project cost.
If you had .NET on the server, you could build a COM wrapped component to do the heavy lifting around System.Net.Sockets.TcpClient. Just a thought.
Related
I'm using Python and QT (PySide) in a local application (which connect to a database on cloud Azure).
Now, my objective is moving this app on the web, in particular on Azure (I have an Azure subscription), simply transfering it on Azure, it's possible in some manner? I have not found examples on the web.
The important question is: is Python QT (app web) compatible with Azure?
Thanks
UPDATED ANSWER!
Yes, now you can. Well sort of. The mad mads at Digia have created something called "QT for Web Assembly" that can compile your whole app into something that runs embedded into a web page.
https://doc.qt.io/qtcreator/creator-setup-webassembly.html
You might have to rethink connecting directly to the database however, as thats simply not gonna fly with web-sockets (And honestly direct app to remote RDBMS has never been a smart move. Theres a LOT of things that can go wrong letting the internet connnect to your databaes). But you could at least keep the UI and rewrite the databaes layer to interogate something like a GraphQL (or whatever) front end to the data.
OLD ANSWER
I'm afraid your up for a nearly complete rewrite. QT is a desktop/mobile platform. It doesn't go anywhere near HTML/CSS except perhaps for displaying them in a webview component. Azure or AWS won't magically make it into a web application for you.
Your code as it stands needd to be rewritten in a web-first transactional manner. That is it takes a request, processes it, produces a result. To some extent websockets has changed this dynamic for a limited subset of use cases where interaction needs to be non transactional, and modern web app design hides much of the transactionality behind a web-services model, but 90% of web work is still very much transactional.
Database <---> Web server/Web app stack <--- Internet! --> Web browser
My suggestion is to pick up Django (or one of the other systems. If its just simple, Flask is another good alternative. Flask for simple apps, Django for the big stuff. Or use something else, you have choices here!, and start from scratch. Analyse your products function and start mapping out how to make this work as a database driven transactional system.
Theres no shortcuts here, I'm afraid.
I've recently created two C# console applications. The first transforms a bunch of command outputs into an XML, and the second transforms the XML into a Word document using a template.
I'd like to know how I could get this onto the web, i.e having a web page where the command output can be uploaded, the two step conversion executed, and finally the Word document made available for download.
Should the web page be created in ASP.NET or are there other (better) options? Do I need to rewrite the console applications in some other format?
This question is fairly broad, with plenty of room for novel sized explanations, but here's a brief highlevel walk through of what likely needs to happen to achieve the proposed results (language agnostic):
Get a hosting provider that allows users to spin up their own machine (i.e. AWS).
Spin up a machine that is compatible with the "console" programs in question.
Install "console" programs on machine.
Install a programming language (i.e. Node.js, PHP, ASP.NET, even C# could do) on the machine.
Install a web server (i.e. NGINX, Apache) on machine, configure it to serve public requests and run with chosen language.
On server request, execute appropriate commands from within the chosen language. Languages typically come with a exec method (i.e. in node.js: require('child_process').exec(command,options,callback))
Get the results of said commands and send it back to the client. Alternatively (for downloads), write the result to a path on the system that is publicly available to the internet and redirect the user to that url (additional configuration might be required to make sure the browser downloads the file as oppose to just serving it).
The steps above should get you pretty close to that you want. As for your questions:
Should the web page be created in ASP.NET or are there other (better)
options?
The "better" options is whatever you feel most comfortable with at the moment, you could always change it later with reasonable effort (assuming that your "console" apps are not unsuspecting unicorns).
Do I need to rewrite the console applications in some other format?
No, unless you have strong reasons to do so (i.e. multi environment compatibility). You could also rewrite to significantly simplify (i.e. bypass working with a CLI and do everything in C#).
Try thinking through these high level steps, begin working on a implementation, and post more specific questions here on StackOverflow when you get stuck.
I hope that helps!
A tester came up to me and told me that a link was creating a dialog with the logical drivers from the server and the desired behavior would be that it showed drivers from the client side.
Since c# is a server side language I only believed that I need to use a client-side language.
Today this application is developed in Asp Net MVC so I went to seach such a feature in asp net.
Turns out there is nothing related to that I could find.
I found that javascript provides "FileSystemObject" that I believe I could do that, but I am looking for a solution using asp.
Any suggestion?
AFAIC, you cannot do this in C#. Software running on your server has no way to access the file system of the client computer. So you do need a client-side language such as JavaScript.
So I would try to get more information from JavaScript people, but I strongly suspect that there are severe limitations on this if it's possible at all. I don't want every website I visit to be able to access my system drives. It's a security risk.
Is there any problems with creating a powershell runspace in an asp.net application and running commands?
I have a basic example working fine but I'm wondering if there are any pitfalls waiting for me.
I'm particularly wondering:
Is this an a light-weight inprocess operation or is it firing up another processes that could lead to unpredictable behaviour.
As long as you're not shelling out to powershell.exe explicitly, instead using Runspace and Pipeline objects directly, you can be assured it's fairly lightweight. Btw, if you are trying to interact with cmdlets through C#, only cmdlets that derive from PSCmdlet need a pipeline; ones that derive from Cmdlet directly can be called without a pipeline via the Invoke method. This is the most lightweight approach.
This should be OK. I've not done this in ASP.NET but I have hosted in-process with a desktop app. There is no external PowerShell process spun up unless you use background jobs. I think the Quest folks are also doing something like this with their Mobile Shell.
As I can see, others recommend using PowerShell. Well, personally, I would pay more attention. Why?
Each web request should be processed as quickly as possible and without any blocking. If the script contains commands that work with network, then there could be some timeouts (e.g. if the computer is not accessible). The processing thread will be blocked for all the time and can't serve any other web request. Then soon you might get Internal Server Error and similar responses.
Besides that (not proved) I suspect that PowerShell consumes more memory than similar code in C#.
I don't claim don't use Powershell, just pay attention ;)
Let me start off by stating that I am a novice developer, so please excuse the elementary nature of my question(s).
I am currently working on a Flex Application, and am getting more and more confused about when to use server side scripting, and when to develop web services. For most of the functionality I am working on, I am taking various files from the user (client), uploading to the server for processing/conversion, then sending back to client in new format.
I am accomplishing most of this using asp.net generic handlers (ashx) files, but not very confident this is best practice. But at the same time, does making web services make any more sense? What would be considered best practice for this? Any suggestions would be greatly appreciated.
The way I look at it is as follows:
Web Services mean Established Best Practice.
For most of our development, we don't need to create "Web Services", or what I'm thinking when I think REST, SOAP, and the Twitter API. You only need to start doing that once you've got something you're going to be using every day for years.
Clean and DRY code will Lead you to Creating a Web Service
If you spend the time to clearly define the parts of your upload-process-render Architecture, and you find that it can be applied to almost everything you are doing, then all you need to do to make it a Web Service is define a clear, 1-2-3 set of rules for using the system (GET/POST data, etc.). As long as you are consciously building an architecture the whole way, you'll end up creating a Web Service if it's worthy. Otherwise there's no need.
It sounds like you have a clear workflow going, I don't know anything about asp.net though.
As far as it being confusing sometimes, and best practices, I suggest the following:
Create a Flex Library Project for your "generic ashx file handling" Flex classes. Give it a cool, simple name.
Create a .NET Library Project that encapsulates all the logic for your server-side file processing. Host it online and make it open source. I recommend github. Test it as you go, and document it, its purpose and the theory behind it.
If you don't have to do anymore work at this point, and it's just plug and chug, then you've probably arrived at something that might become a Web Service, though that's probably a few years down the road.
I don't think you should try to create a Web Service right off the bat. Just make some clean and reusable code, make a few examples, get it online and open source, have others contribute and give feedback, and if it solves a specific problem, then make it a web service. You can just use REST for now probably, and build your system around that. RestfulX is a great library for that.
Best,
Lance
making web services without any sense make no sense ;)
Now in the world of FLEX as3 with flash version 10, you can easily read local files, modify them with whatever modifcation algorithm and save local files without pinging server.
You only have to use webservices if you want to get some server data or to send some data to server. that's all.
RSTanvir
Flash / Flex uses a simple HTTP POST approach for file uploads, so trying to do that using SOAP web services will be problematic. Your approach of using ASHX here sounds reasonable to me.
To send / receive data that isn't file based (e.g. a list of files the user has uploaded previously), I would recommend looking at the open source Fluorine FX library. Fluorine uses AMF which is a highly performant way of doing data transfer with Flash. It's also purely configuration-based, which means you don't need to code against any of its APIs, just configure Fluorine to expose your .NET service classes. You could easily add attributes to those same classes to expose them as SOAP web services via WCF if you need that in the future. I would not recommend using SOAP with Flex however, due to the performance losses and also because the Flex implementation of SOAP has a history of bugs and interoperability problems.