So I pretty much exclusively write windows drivers, kernel mode, and its a very demanding environment. Lost of issues with concurrency, and something you user mode guys wont have come across, priority. Your code can be called at PASSIVE_LEVEL, DISPATCH_LEVEL, or, if you have an interrupt, some kind of DIRQL.
Now when you are at elevated levels, you cant touch pageable code or data, it has to be non paged, else you risk a page fault crash. You also cant wait or sleep, or allocate non paged memory at elevated levels.
So something I use, architecturally a lot, is a function call queue, and a thread, which runs at PASSIVE_LEVEL (thats real time priority by the way) to empty the queue.
Because only one function at a time is run by the thread, when taken off the queue, data cant be touched at the same time, and because the thread runs at passive level it can wait, and can call any function, or use any data.
And its very easy to use. Any event that occurs, just save the relevant data in a context, and queue it.
The whole functioning of the driver becomes very relaxed. Almost nothing needs locking, and almost all code runs at a low priority. Its a very good solution to highly complex environments and makes for aq very good product.
FlagComposer: let's build a software tool using XML to define a set of national flags.
This project is mainly addressed to students or programmers who'd like to have a challenging programming task to solve as an exercise in their free time…
So, here is the description…
Let's imagine, we want a software tool to define a set of national flags. The tool should use XML data to (1) draw a GUI and (2) to generate an output.
Aim of this application is to build a GUI starting from a XML file (e.g., see "FlagComposer.xml" in the GitHub linked at the end of the post) and to generate an output XML file (e.g. "FlagGermany.xml") according to what has been set by the user in the GUI.
In input we have one (or more… but not simultaneously processable) XML file(s) defining which elements (graphical controls) should compose the GUI, which parameters are needed to define a flag, which values are valid; in output we want to have one XML file for each flag definition. It is not required to display an image of the flag: the XML file is all that we want to have as a result of the processing.
The application must read a XML file containing a "GUIDefinition" element and draw a graphical user interface accordingly. It must also be able to generate and write out a XML file containing a "FlagDefinition" element.
[Application is launched] ==> [Read XML <guidefinition>] ==> [Draw GUI accordingly] ==> [Process user's "Save" or "Exit" command] ==> ["Save" creates XML <flagdefinition>] ==> [Exit]
Starting from the <guidefinition> element of the input XML data, we want to build up a GUI where the user can enter the required parameters, for instance (…see "FlagComposer.xml"):
1. a "Name" should be entered through an editable text field;
2. a "Direction of Stripes" specification should be entered through a list box (or choice box) displaying the available options ("Horizontal" and "Vertical") and allowing the user to select one of them;
3. a "Number of Stripes" should be entered through a numeric spin box ranging from "MinValue" to "MaxValue" (eventually initialized to a "DefaultValue");
4. a set of list/choice boxes should allow the user to enter the colors of the flag: the GUI must provide N occurrences of the "Color of Stripe" parameter (list/choice boxes) according to the previously set "Number of Stripes".
Once the user has entered all the required data, an enabled button or menu option should allow him to generate and save the output XML file with the final <flagdefinition> element (to have an example of the output file, see "FlagGermany.xml").
To develop the application, free or open source tools should be preferred over commercial ones, but the choice of the programming language, IDE and framework, with which to implement the application, is ultimately left open to any option and demanded to the programmer (that is, to anyone who's going to try to implement a solution to this problem): you may choose whatever language or framework you like. Of course, the simpler and faster-to-implement-and-maintain the solution is, the more it will turn out valuable.
A set of XML files, to use as a model of the input data (<guidefinition>) that should be used by the application and of the output (<flagdefinition>) that should be produced, is available on GitHub (there you'll find XML data files only; there's no source code, as the application doesn't exist yet…):
Please, fork the GitHub project to suggest your ideas or your implementation of a solution…
As you can see, the application that I'm asking you to design (and eventually develop) is just a "toy", but it could give me the crucial hint necessary to deliver a solution in the professional field where I'm working… and - yes - to save my job! (In the company where I'm currently employed I'm struggling to solve a problem with several technical analogies already since a long time, unfortunately without success till now… Well, I'm just a junior developer, after all; I hope you'll understand…)
XML is a ground requirement in this "FlagComposer" simply because it is a requirement (for the communication between many software components, having distinct producers even) in the project I'm professionally working on. For understandable reasons, I couldn't post anything related to the real project… but in the "FlagComposer" problem (note again that there's no such application yet!) a few technical aspects of the "real" project, whereto I have to deliver a solution, are reflected.
Also links to useful resources and to existing source code doing more or less what is involved here could be very helpful! Any contribution will be very appreciated! Thanks a lot in advance!!!
The application that I'm asking you to design (and eventually develop) is just a "toy", intended to explore the possible solutions to a problem with the described technical requirements (in short: XML input to generate a GUI; XML output to return an answer to the user): I'm not aiming at representing faithfully all the graphical characteristics of the flags of the countries of the world; painting the flag graphically is not required and doesn't interest me at all, indeed. Unfortunately, I couldn't think of a better sample project to explore the issues that I'm facing with the industrial software I'm currently dealing with…
The application that I'm asking you to design (and eventually develop) is just a "toy"
So, you said in your original message that you want us to do this to save your job. Unfortunately, that's not the way we work here - if you want code to order, try RentACoder (or whatever it's called nowadays). You have to understand that we are all volunteers and the vast majority of us code professionally, so we don't have the time or inclination to write this for you.
It sounds as though you're trying to create a "XAML" style of application - search for Marc Clifton's excellent MyXaml series of articles. These should help you.
Thanks a lot for the tip, Pete! Tips that puts me hopefully on the right path are exactly what I'm looking for… Unfortunately, Clifton's www.myxaml.com website is not reachable… maybe the MyXaml development technology is something obsolete?
I'm planning to develop a Winsock Layered Service Provider. Given that the provider DLL will end up being loaded into system processes as well as user ones, are there any restrictions on the uses of the C++ runtime and/or MFC inside these processes?
Am I going to have to develop it in straight C? (I hope not.)
When I say system processes, I mean user mode system processes. The LSP is not a kernel mode component.
The difficult we do right away... ...the impossible takes slightly longer.
I personally wouldn't recommend using MFC for anything that doesn't involve a GUI. It's relatively large and really buys you minimal help for most things (although it does help a lot with GUI objects).
As to building this type of DLL using C++, sure, you probably just need to export some functions using the 'C' style exports so they could be loaded. It's common practice so you'll find examples everywhere.
I'm currently in the process of investigating how to best implement a common login system for all our applications. The logins can have different types of users: some are system users or even crowd sourcing members, others are used for determining user settings for an application and others are subscribed to newsletters or alerts of some type.
The idea is to have one common database of users or contact information which all applications can use, similar to an SSO system.
apart from the usual advice: password rules, encryption methods (using salts), SQL injection, using secure transport etc... I don't find that many tools that allow this (preferably for free, like an open source thing) and honestly, perhaps I'm overly suspicious, one is never sure they tackle security right and whether they are flexible enough to handle 100% of the requirements. And finally if they are easy in maintenance and usage (installing, configuring or compiling, ...) ?
Secondly you have the openid, oauth, ... systems that allow social media login. Looks nice, but I have the feeling that you never get all the information you want and this is also on provider's goodwill (IOW they can stop the service at any time, not that they will, but they could?) and the technology could change, forcing you to evolve on a regular basis. Lastly, though I'm not 100% sure, I seem to remember reading somewhere that more institutes/companies are stepping away from openid (I think in favor of another technology). Can't remember the source.
question 1: Any recommendations on a system? Free or paying.
question 2: Why would or wouldn't I adopt a social media SSO?
question 3: apart from the logical things to watch out for: any additional advice?
This system goes wider than the domain. Some stranger can register and subscribe for any of the services we provide. I'm guessing yahoo, twitter, facebook, ... don't use ldap to register their user, right?
Well that's the crux of the issue. You could introduce a guest OU that has groups and user slots for the psudo-anonymous users off the network, but generally that's more overhead than should really be required.
The reason that I mention this is that you said you're looking for a single login mechanism, but handling LOB accounts and unverified accounts should be inherently different (an unverified account should never be granted admin access, but if you use a semi-trusted authentication system how do you handle fully trusted authorization?).
So there's a few approaches. One is to add all users to the domain as mentioned and use a Guest container. Another is to use a mechanism like OAuth2 (and provide an OAuth provider from the domain for LOB accounts) and move administration to a separate application that is only available to domain accounts. That doesn't meet your single AAA criteria, though. Or you could setup an authoritative database, but that would place your LOB accounts at the exact same security context as your unverified accounts without a bunch of code overhead, which is not something I could suggest.
Ultimately I'd say that the requirements need to be reviewed. I'd personally suggest using domain authentication for applications that provide administrative access, and using OAuth2 for public endpoints, but I'm not familiar with your system and overall requirements. This has the benefit of having a single authentication mechanism per application purpose, without co-locating AAA information.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
It's not an easy task (we have lot's and lot's of history which resulted in a mess I'm now trying to clean up, ... a little) and the requirements will be more definitive when I talk to the necessary people concerning budgets and timing. I'm just gathering information for now on what's possible and what would be the best approach in which situation. Your answer is definitely helpful in that regard.
Best of luck. The real problem you're going to face is to convince management to get behind a system that's designed to be security-minded from the ground floor. Fortunately(ish) 2016 was a hack-heavy year, so you'll likely get less push-back about "intangibles". Silver linings.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
there is the saying "one picture describes more than thousand words".
I also find myself in a situation, where an image inside the source code would describe the situation so much faster and easier, than text. Especially for non-technical domain code.
Therefore, I think enabling images inside source code would be a really awesome, helpfull extension. But as a matter of fact, this feature does not exitst. Am I maybe missing something here? What's your opinion on that topic?
I think, New Year party left you in a hangover or something like that. But, a programmer leaves billions of errors in just a few hundred lines of codes. What do you expect him to do in thousand words, moreover in the form of image.
Of course, there are some source codes where you can embed images, they are called HTML codes.