I'm building an app that will run on our network for job tracking with two user levels, one for general users and one for administrators.
How are user systems usually implemented in Qt? For example, how are user state and user roles handled? Should I just include a C++ class and set these types of things as properties within that class, or are there established and well documented "best practices" for implementing user systems within Qt?
I also need to be able to share user state and role among various classes. For example, the menu class needs to know the user state & role to know what items to display.
Any help is appreciated!
What you are asking for doesn't make sense in terms of Qt on it's own. Qt is a framework for local client apps. The Qt application displays it's information to only 1 user at a time on one display / desktop at a time.
You framed the question in terms of a networked job tracking application. Lets assume this implies there is some sort of job tracking server. Likewise, let's assume you are writing a client for this server application in Qt. In this model you could let the Qt application login to the server using credentials provided by the user. Then it would be the server's job to tell you whether the user is who they claim to be and what role they have and to enforce any security restrictions.
Since you say you are familiar with web applications, lets draw an analogy. Qt is intended to provide you the tools to write the web browser only; you would still need to provide the the web server and web application to run within it. Thus
Qt application is to web browser as X is to web server.
You have to provide "X", and that is where you implement the user system.
Of course Qt does provide basic support stuff like network sockets, but on it's own I don't think it's well suited to writing a server application.
Related
I am in the process of designing an application that users will be able to log on remotely and use - via a web interface.
Security is of paramount importance (think credit card and personal banking type information)- so I need to make sure that I get the security aspect nailed down - HARD.
I intend to provide the application functionality via traditional (stateful) web pages , as well as web services.
For what its worth, I am intending to use web2py as my web application framework.
Is there a list of guidelines I can follow to make sure that I have all areas covered?
One stop shopping: https://www.owasp.org/index.php/Main_Page
Read that and take every suggestion to heart.
you should consider at least the following:
authentication. getting users to log on in some manner. which authentication method they use depends on what you aim to provide
privacy. making sure the information they send is only visible to them and your application and not an eavesdropper.
in the simplest case SSL can take care of both of the above. it will always provide encryption but can also be used to authenticate or at least make some simple authentication mechanism more secure. one thing to look at is security of ssl. ssl is suceptible to a man in the middle attack particluarly when the users already have a trust relationship with, say, their employer - who can them proceed to install an ssl gateway which is effectively a mim.
authorisation. making sure users are only allowed to see what you want them to see and no more.
this really depends on technology you are using.
non reputidation. making sure the user cannot dispute the actions they perform
this is a very open ended question. legally this is seldom (never?) used so it depends... something like signed logs of user requested actions for example is probably enough.
Your biggest threat, by far, is writing server-side webapp code that introduces vulnerabilities in your web application layer. This is not something you can checklist. For a starter, make sure you are 100% comfortable with the items in the OWASP Top Ten and understand how to code safely against them. If you are not expert in web application vulnerabilities, strongly consider hiring someone who is to help review the web layer. At the least, i would consider contacting a security testing company to perform some form of penetration testing, preferably with a code review component.
If you ever do anything with credit card data, you will need to comply with the PCI DSS which will require at least quarterly remote-testing from an Approved Scanning Vendor.
I have a specific question about Java EE architecture. I have an application that requires several components:
A web service and persistence layer (cxf/hibernate)
A management / configuration console (Struts2/JSP?)
One or more user "applications" (Maybe Vaadin?)
Note, the web service will provide services to the user applications.
The web service has been built as a cxf/glassfish application (Eclipse dynamic we app) and is working well.
Should the management and user applications be developed as entirely separate applications (EJB's or ?) or form part of a "single" application with the web service. I am not sure if I am explaining this well enough - but I am new to this sort of design and am trying to approach the solution in a well structured way. For example I could imagine that taking an approach of separate services (applications) could result in:
Primary web service (does common data persistence stuff)
Authentication service
Management App service
First user App service
Second user App service
Each of the user apps is likely to have both common and unique data persistence requirements.
To decide how to split your implementation, you should consider your system through different views. In software architecture, there is a very useful method which is called the 4+1 architectural view model (http://en.wikipedia.org/wiki/4%2B1_architectural_view_model). Using the Physical view you will be able to decide if you may need to install the different components in different machines, and this will help you to define your development view, that will give you the answer to your question -> how to split the different components of your system in a development point of view. Once you have the development view, you can define how the components communicate (process view)... and so on.
This views have always helped me, I hope you find it useful.
I am having a desktop application which having a UI interface made in Qt linked with a library which is doing all the calculation stuff. Values from UI is taken and pass to the API's in the DLL to get the output which is shown on Screen.
Now i want to do the same thing by transferring my application UI to a web page so that people can access the tool from anywhere without any installation process.
I want to retain my c++ DLL code so i don't have to do a lot of work. I am thinking of just converting this DLL to a C++ server by any communication Process(Sockets). I want to host this application on my company's website. (We have to make the website also so we are open to any set of tools).
I want to know what will be the best set of tools to do this stuff. Also there will be lot of data exchange between the webpage and server so the wholething should be optimized also. I goggled a bit and find stuff like silverlight and ASP.NET, But i am still not very clear which option will be more suitable.
I am a c++ programmer with no web application development experience. I am open to learn any new technology.
Thanks
Why not use Qt on the web directly? There are several projects like this one: http://qtwui.sourceforge.net/
There is a netscape plugin that will host a QT application and an ActiveX control wrapper on the QT website. You could use one of those to wrap your application. Note that this approach would require the user (or their administrator) to download and install the plugin.
An alternative approach might be to run your application through a remote desktop such as XVNC, NX or an RDP based layer. IIRC browser based remote desktop clients are available for most such protocols.
A few options:
pick a messaging/queue implementation (like http://www.zeromq.org/) and provide a service
implement a Windows Web Service if you want to be more enterprise friendly: http://msdn.microsoft.com/en-us/magazine/ee335693.aspx
I would not expose the implementation on the internet. Enough to have a simple buffer overflow and the machine can be taken over quickly. Adding a layer between the app and the web provides an easy way to validate input, access, stats ...
You should be able to use your DLL from an wt or cppcms application. Then you do not have to learn something new and can just use C++.
The way I'm currently doing this is with Boost.Python + django
This is not a question about writing a web-app Vs a desktop app. It's a question about allowing a bespoke application to run in a browser though use of a custom plugin, effectively using the browser just as your render-window.
QuakeLive does this - it's a C++ application with some extra code to run through a browser. Unity3D and Torque game engines also provide deployment options to do the same thing.
Personally, I'm a bit dubious about the usefulness of such a system. But I'd welcome other opinions on the reasons why this might or might not be a good idea.
Not sure if there's a proper term for this, please edit my tags if there is!
It depends on the application. My background is in medical imaging, but what I have to say would apply to many information system clients:
Pros:
it gets easier to build REST-based integrations between applications. This type of integrations can be used by admins to build integrated portals. (So case ID's from one application can be used to launch another with the right context etc).
ideally, users can install your application themselves, on-demand (depends on context if this is really possible)
Deployment of new versions gets easier. Usually the hosting technology has deployment built-in. In client server environments, this can save a lot of work for the IT department.
You can have a single start URL for PC's and thin web clients (like phones). This makes it easy for users to find your application.
You can centralize configuration for clients. For standalone clients, you could of course centralize configuration somehow, but if you app is web based, you always know for sure there is a server, so you can always use it.
you can offload work that's ineficcient to do locally to the server. (reduce # of roundtrips between client/server).
Cons:
Each browser vendor has its own model of wrapping the native code. There are not too many, but it's definetly extra work.
Your app has to "play nice" with the hosting application. Like when the user closes the browser window, the browser may have prescribed when and how you can ask the user to save.
updates to browsers can break your plugin.
system admins may have restricted installation of plugins, disallowing users to install your application on demand (this happens a lot for activex).
your users may not like that extra code is injected into the browser (there is a lot of malware around that does this)
you don't have the opportunity to update prerequisites before installation
I don't believe really that it's just wrapping existing code in a plugin framework.
Your application won't work anymore when the server is down...
I work at a company with a large SAP investment, and we also have dozens of large .Net systems (mostly internally for engineering systems), and Java platforms (mostly for external web applications). As such, we have large development shops on ABAP, C#, and Java EE.
We have decent standards for which platform to use in which domain, but we don't have a lot of clarity around when to use web UIs and when to use desktop UIs.
I've seen some excellent research on this topic in the past (like this), but I'd like something a little more structured
I'd like to build a decision tree based on best practices to help with this question.
Some of the criteria I've seen in the past include:
Is the application targeted to users
with different OS configurations?
Does the application require OS-type
functionality for sorting and editing
data? (I know that AJAX /
asynchronous JS has made possible
much richer desktop-like
functionality to web applications,
but some would argue the desktop is
still king in this area)
Will a web application be able to
provide the availability,
responsiveness, clarity, and utility
that can be delivered with a desktop
application?
I think we are seeing the separation between Web and desktop applications softened quite a bit. Rich internet applications (with Flex, Silverlight, Ajax) started this trend, and WPF with XBAP is taking the user experience of browser-based applications to another level.
It is becoming a bit more involved to have this argument, because there are now more flavors in the spectrum between Web and desktop apps.
Some more questions to ask:
What is the primary objective of the app - data manipulation, or data viewing?
What is the number of data points/records that need to be viewed/edited together on one screen?
What is the organization's IT infrastructure look like? Will they be able to accomodate new deployment models?
Will users work with a central database from remote locations?
Does the organization have a VPN infrastructure of off-site users, and how do users authenticate?
Are there existing applications that the same user group is working with, and how are these applications deployed?
Does the application need offline capabilities?
Given that they are so different, what is the skill set of the development team for web and desktop APIs?