I'm using a product that utilizes the Qt QWebPage class. I'm surprised I haven't seen posts, but I'm having trouble getting this to load a website that utilizes Windows Authentication. Does anyone know of any support to pass along credentials or load a page as the default user who is executing QT?
The question feels beyond Qt. To deal with Windows Authentication we can probably use QAuthenticator class but the applicability of it remains a question. You want to deal with web interface and use authentication? Then many more details needed and depending on those some specific programmatic solution can be applied. I assume you need to deal with HTTP/Form authentication as well and that needs to drive post/get requests. Somewhat similar answer. My current project involves many types of authentications and we have a specialist on the team just for that. It is all about network/application security logic.
Are you handling proxy inside your code. Also you must use Qt version 5.3 or greater to support NTLM authentication.
Related
I am coming from a background in Web Development. Have had some classes in MS access about 3 years ago. Currently I am working on a project primarily built using Access. Eventually the program will be expanded to interface with the same database that Access uses in the cloud. Which will then lead to development on a web project.
My question is its 2017 and I am aware that you can make web calls in Access , but just because I can doesn't mean I should right ? My client/boss would like to implement a credit card processing payment system into his Access application. However I am pushing for this to be something built from the web development side project that will take place later using an API. Any Access developers out there able to suggest whether its a good idea to wait to build this feature later when development has begun on the web project ? Is it okay or secure to make web calls using Access ? Or is there any alternatives to an existing merchant service that can interface with Access ? Any advice on this topic would be greatly appreciated. Thanks in advance.
Access (VBA) has COM support, and makes heavy use of it. Any existing merchanting solution that works with COM can work with Access.
If your desired merchant solution doesn't, you can create COM classes and libraries in C#, C++, VB.Net and probably some more programming languages.
If it's a good idea? That heavily depends on your demands. I don't know what the advantage of an Access database over a program is for you.
Note that if you're using ASP.Net for your web solution, you might use a common class to check and authorize payments, and you might want to develop both simultaneously.
I am a little confused as to how the identity framework works. For example in VS 2013 we can create an MVC application that the authentication is individual user accounts. Once we create it we can register with a username and password. But what if we wanted to have also a DOB in the registration or some other fields such as email or phone etc? Can we do this with the identity framework? What about the way the data base is structured, can we have a custom structure? Or if I want this should I be using forms authentication? Also what is the difference between the Identity framework and Forms authentication in terms of authentication?
Although your post has already been marked as answered, I’d like to add a little more info for future readers.
The first thing we need to understand with VS and Microsoft is that they’ve always tried to provide us with Templates to help us get started. There are many Pros and Cons to using Templates but the idea is that it gets you started quickly without having to manually include stuff yourself.
The idea of Templates is great but to the untrained eye, it provides Microsoft an opportunity to include stuff that THEY think you’ll need or better yet, what your application will need.
This opportunity includes promoting products such as Identity, Knockout.js etc...
In short, Microsoft is not wrong in doing that since the majority of the people do not second guess what is included in their project and because they…well…trust Microsoft.
A great analogy is when you purchase a new computer from a major retailer. When you arrive home and start your computer, you quickly notice that you have a bunch of pre-installed software running in the background (that you never asked for).
To the untrained eye, they will never realize that these are running in the background and their computer will work regardless. But for someone that is aware, he will most likely uninstall all of them and have a cleaner plate.
So Templates are similar to this...
As for the rest of your questioning, I’m sure by now you’ve found the answers.
Even though Microsoft sells ASP Identity as a single solution, Forms Authentication and Identity (Membership) are two distinct frameworks that work together, but serve different purposes:
Forms Authentication manages authentication session/cookies.
Membership/Identity is the store for user information (credentials, user demographics, etc.)
Look here for some additional information and links.
I was looking for a solution to sign XML using unexportable private key (this require passphrase/secret password to be informed by user input for create the hash using it) contained in usb token (smartcard etc) for a web application. I have made a c# class library to make this but obviously the code is executed in server-side, so I can't access the usbtoken/smartcard of the client over internet, unless it's plugged in the server pc (so my solution may be installed in local network of my customers and the usbtoken plugged in server's usb. It's working like that today but I want to change this for the customer use its token in his machine)
I have created a code using SignedXml, X509Certificates and other classes, to achieve this, but I was looking for equivalents in silverlight class library for encapsulate all this things and execute it in client side, but unfortunately SignedXml can't be used in Silverlight (not exists..).
I have created an ActiveX for doing this successfully but my solution now only works in Internet Explorer/Windows, and it's not very easy to maintain because of my business logics.
Anyone can help me with this please? Any suggestions are very welcome.
If I can port my activex solution to silverlight, or if its possible to do that using other MS Technology that can be executed in other browser/OS.
Sorry for bad English, not a native speaker. Thank you.
Java applet is a better option than the ActiveX.
Silverlight won't give you access to certificate storages, and its development has stopped (Silverlight 5 is officially the last version).
Our company offers a ready to use solution for distributed cryptography which includes ActiveX, Java applet and Flash module for client-side activities. This solution is discussed in details in this answer.
I just discovered ASP.net uses its own profile system to register users and there seems to be a lot of features available as bonus with it (such as secure authentication). However it seems rather specific to have such a feature for a general purpose development environment and things which work in the background the way the profiles system does without me really knowing how (like where the user data is stored) kind of scares me.
Is it worth developing a website which requires user authentication using the asp.net profile system or would it be better to develop my own using SQL databases and such? I'm not going to avoid using SQL anyway, even if I use profiles I'll use the profiles unique ID to identify user data in the SQL table so in that sense I'm not going to avoid using SQL for user information at all.
My favorite thing about profiles is that you can create custom permissions in Web.config files using them () and avoid having to type in the same code to the top of all your aspx source files to do the authentication check.
The other thing I kind of like about it is that security is built in with secure authentication cookies, so I wouldn't have to deal with them myself.
But it doesn't seem like that big of a deal really. I'm just confused as to where profiles stand as far as ASP.Net development goes and what they're designed to accomplish.
The Profile/Membership and Role provider API is very intertwined, and specifies things very narrowly. The benefit is that there is little you have to do to get a lot of functionality working. The disadvantage is when what you need doesn't match what is provided. Nevertheless, there are many potential gotcha's that the API takes care of for you that it really does make sense to use it, at least for authentication.
My needs did not match what the API provided, and I really only needed the Membership portion. The problem is that I had a piece where I needed to use the same authentication and authorization across a web application and a desktop application. My needs are pretty unique, but it's designed for a classroom setting.
Getting the membership to work for my needs wasn't that difficult. I just had to implement the Membership API. There are several features I just didn't need with the Membership API like self-registration, etc. Of course this did present me with a challenge for role management. Typically, as long as your user object implements IPrinciple it can be used directly--but there are serialization issues with the development web server Visual Studio packages if your user class is not defined in the same assembly. Those problems deal with serialization, and your choices include putting the object in the GAC or handle cross-appdomain serialization yourself with objects that are in the GAC like GenericPrincipal and GenericIdentity. That latter option is what I had to do.
Bottom line is that if you don't mind letting the API do all the management for you, than it will work just fine. It is a bit of smart engineering work, and attempts to force you down a route with decent security practices. I've worked with a number of different authentication/authorization APIs (most were not CLR based), and the API does feel a bit constraining. However, if you want to avoid pitfalls with session/state/cache management you really need to use the API and plug in your own providers as necessary.
With your database, if you need to link a user with any database element you'll be storing the user's login id (Context.User.Identity.Name).
You seem to mix the Profile/Membership/Role provider API. But to answer your question: why not use it? I would use it unless there is a real constraint that makes it unusable...
I am about to write a tender. The solution might be a PHP based CMS. Later I might want to integrate an ASP.NET framework and make it look like one site.
What features would make this relatively easy.
Would OpenId and similar make a difference?
In the PHP world Joomla is supposed to be more integrative than Druapal. What are the important differences here?
Are there spesific frameworks in ASP.NET, Python or Ruby that are more open to integration than others?
The most important thing is going to be putting as much of the look-and-feel in a format that can be shared by any platforms. That means you should develop a standard set of CSS files and (X)HTML files which can be imported (or directly presented) in any of those platform options. Think about it as writing a dynamic library that can be loaded by different programs.
Using OpenID for authentication, if all of your platform options support it, would be nice, but remember that each platform is going to require additional user metadata be stored for each user (preferences, last login, permissions/roles, etc) which you'll still have to wrangle between them. OpenID only solves the authentication problem, not the authorization or preferences problems.
Lastly, since there are so many options, I would stick to cross-platform solutions. That will leave you the most options going forward. There's no compelling advantage IMHO to using ASP.NET if there's a chance you may one day integrate with other systems or move to another system.
I think that most important thing is to choose the right server. The server needs to have adequate modules. Apache would be good choice as it supports all that you want, including mod_aspnet (which I didn't test, but many people say it works).
If you think asp.net integration is certanly going to come, I would choose Windows as OS as it will certanly be easier.
You could also install reverse proxy that would decide which server to render content based on request - if user request aspx page, proxy will connect to the IIS and windoze page, if it asks for php it can connect to other server. The problem with this approach is shared memory & state, which could be solved with carefull design to support this - like shared database holding all state information and model data....
OpenID doesn't make a difference - there are libs for any framework you choose.