The bigger goal:
Writing a batch user manager targeted at classroom school environments.
The problem
I want to write a user manager that uses a GUI to add, manage and delete users for classroom environments. The program I'm working on is ltsp-manager.
Up until now all the user management is done by executing bash commands. From a python script. Meaning all the GUI has to run as root and everything is handcrafted.
The goal
Create a Dbus service that handles all the account management and let the GUI run as a regular user requiring a password from time to time.
I looked around and found that in org.freedesktop.Accounts there is already a service doing a lot of the functionality I want to do. However, it also lacks some. Something that is totally missing is the management of Groups.
What is a good way to use the org.freedesktop.Accounts functionality and add some additional functions/methods?
Thoughts so far
Things that came to my mind include:
just redo everything - meaning a lot of duplicated work.
copy the interfaces and write functions that call the original ones
write a service that only implements the additional functions without touching the original ones. The client will then use the original service and the newly written one.
All my testing experiments are done with python3 and pydbus which seems to be the best choice among many.
I have never written a real world dbus service - though the experiments do show some results in d-feet. This question is not really a what do I need to type kind of question but rather a best practise question.
The best long-term answer would be to fix accountsservice upstream to implement groups support. There’s already work towards that; it just needs someone to pick it up and finish it off. accountsservice is the project which provides the canonical implementation of org.freedesktop.Accounts.
The other approaches are bad because:
just redo everything - meaning a lot of duplicated work.
As you say, this is a lot of duplicated work, and then you have to maintain it all.
copy the interfaces and write functions that call the original ones
That means you have to forever keep up with changes and additions to accountsservice.
write a service that only implements the additional functions without touching the original ones. The client will then use the original service and the newly written one.
That doesn’t come with any additional maintenance problems, but means your service won’t integrate well with accountsservice. There might be race conditions between updates on your D-Bus objects and updates on the accountsservice objects, for example. You won’t be able to share the maintenance burden of the groups code with the (many) other users of accountsservice.
Related
I have two node apps running on my server, each performing different tasks.
However, I now need to create a service that is going to be used by both of them. Obviously I don't want to create it in both of the apps, hence creating two codes to maintain.
My current thought is to have a separate repository only for this service, then require it from each app as an outsourced module.
I was wondering whether there are better methods, or if this method might encounter problems I'm not seeing
Well if you strictly follow the rule that shared means only shared things in the common package, I don't see any issues with that. The problem comes when you try to put the logic in one repo which is supposed to be only used for one. In that scenario you will need to rebuilt both apps as the repo or package is depedency of both.
One issue that I have seen people face is when they work with shared repo is that when you need to tweak things just because they are at common place. for example you have a method that does one job and suddenly you want to use that in other place as well but with a tweak. In that case you end up modifying the shared code to support the second repo but since it is shared, you will have to do regression testing of both apps.
I see shared repo candidates being drivers, client etc. I guess rest is up to your project structure and judgement. In this case there is nothing correct or incorrect. Hope this is making sense.
I wrote a node application which will be embedded in the client. I would like to protect my code so the client will not be able to modify it (license check for example).
I already read (and try) this one but obfuscation (and minification) can be reversed and I can't move critical code to an external service (the node application may not have external internet connections).
Is there a (native) mechanism to sign a node application? Something which will prevent the app to run if the code is changed?
There is not a native mechanism to sign JavaScript code. This has been attempted in the past but scrapped quickly.
Checkout this question and its answers on how difficult this is. User Mason Wheeler sums it up well:
It's been tried. Many, many times. There's an entire sub-industry dedicated to attempting to use encryption to keep users from accessing a program as they see fit. And it never works.
If you want to attempt this anyways, I recommend a commercial product like jscrambler.com for trying to 'defend' your code with encryption and self-defense techniques. There are so many drawbacks to doing this yourself that it isn't worth it.
Also - keep in mind that for every change you make to your code (minify, obfuscate, encryption, etc.), you increase the possibility that your code will not function properly. One more reason to avoid it and/or use an commercial/supported product.
I will soon be developing an application to log and priorities worker shifts. It only needs to be small, and simple, but I am wondering what framework to use. All that needs to happen is boxes with names are in 3 lists, and the user can switch these around at will. It must log the times, which I will need access to in real time.
Im new to application development of this sort, and would like any suggestions. I have time to learn new technologies / languages.
Portability / device independence would also be useful. Should I consider a Web Application in Javascript? or something more like Python.
Thanks.
Even if your application is going to be simple that does not mean that whole system will be simple too. I can imagine that your app will serve only as a front end to something much bigger. If that is a case and you really have freedom to choose what language you will develop your app with consider choosing something that you will feel comfortable to work with. But before you will make your decision I would go to whoever gave you that task and try to get as much information about it as you can because expected features can help in choosing technology.
First of all, it seems that it is up to you to decide if it should be web or desktop app. In my opinion it is completely wrong situation. You should get clear requirements on what kind of application customer expects and in what environment it should work. And I would not move a finger towards a code before somebody gave me that information. You write that portability and device independence would be useful but is it actual requirement or you just think it would be nice feature to deliver?
EDITED (to answer a question in comment)
Probably there is as much possible solutions as people that would answer you so in the end you will have to make your own choices.
One way of doing it (considering that you want to learn something new and have a challenge :) would be implement WCF service that would act as a data provider from your database (so every GetUsers(), GetVacationDays() methods would be in it) and it would take care of some business logic (for example CalculateMaxValidWorkingTime() or whatever). That service would be a real power horse of your system. Since you don't have clear requirement whether it should be desktop or web app you could satisfy both possibilities by creating thin clients that would communicate with your service and they would be just a pretty front ends. And if you keep in mind that you can consume webservices practically with everything from C++ to .NET (C#/VB) to Javascript to Python to PHP after you done with service you would not be constrained with one particular technology/language.
Regarding databases I won't advice because personally I hate dealing with them and it always was somebody else's task to provide me with pretty API :)
For some time I have been looking at the possibility to integrate PowerShell as a scripting engine in SharePoint but I haven't found the right solution yet.
My main objective is to enable event triggers in e.g. a list to call and execute a PowerShell script (by filename) on the local server. This would give me a lot of flexibility compared to using an ordinary event handler written in visual studio, but the question is whether it is possible and whether I have overlooked some serious security issues?
Since each and every unique idea that I come up with in many years have already be invented by somebody else, I might have missed an existing product/project so any links to such projects will be appreciated, thanks
In the spirit of "already being invented by somebody else", check out http://www.codeplex.com/iLoveSharePoint for some very interesting uses of PowerShell inside SharePoint. Some great code samples and documentation. Haven't tried myself yet, but seems interesting.
I see what you're trying to achieve, but there's something that just doesn't "feel right" about a user indirectly running script code on your server.
The key difference is that the script can be run by anyone logging into the server. Event handlers can only be run by SharePoint. Strict validation of any inputs would be essential. You should also ensure the script is signed so tampered scripts won't execute.
Also, scripts by their nature aren't really designed for enterprise solutions. There is less opportunity for best practices such as good software architecture, design patterns, source control, code analysis, unit testing, and reuse of code. It's also messy/difficult to share code with a common code base that contains web parts, controls, entities, etc.
Finally, introducing PowerShell means another technology to be maintained in the mix we already have with SharePoint. This might be OK if you are comfortable with it.
Depending on how much customisation has already been done or is planned for the future some of the points above may not matter. Be sure to think about how this idea would feel if implemented 6, 12 and 24 months down the track.
I'm trying to write a tool which lets me inspect the state of a PowerBuilder-based application. What I'm thinking of is something like Spy++ (or, even nicer, 'Snoop' as it exists for .NET applications) which lets me inspect the object tree (and properties of objects) of some PowerBuilder-based GUI.
I did the same for ordinary (MFC-based) applications as well as .NET applications already, but unfortunately I never developed an application in PowerBuilder myself, so I'm generally thinking about two problems at this point:
Is there some API (preferably in Java or C/C++) available which lets one traverse the
tree of visual objects of a PowerBuilder application? I read up a bit on the PowerBuilder Native Interface system, but it seems that this is meant to write PowerBuilder extensions in C/C++ which can then be called from the PowerBuilder script language, right?
If there is some API available - maybe PowerBuilder applications even expose some sort of IPC-enabled API which lets me inspect the state of a PowerBuilder object hierarchy without being within the process of the PowerBuilder application? Maybe there's an automation interface available, or something COM-based - or maybe something else?
Right now, my impression is that probably need to inject a DLL into the process of the PowerBuilder application and then gain access to the running PowerBuilder VM so that I can query it for the object tree. Some sort of IPC mechanism will then let me transport this information out of the PowerBuilder application's process.
Does anybody have some experience with this or can shed some light on whether anybody tried to do this already?
Best regards,
Frerich
First, the easy answer: I think what you're trying to do has been done, sort of. Rex from Enable does what I think you're after, but IIRC from talking with the developers, it depends on code hooks built into the application.
Which leads to the suggestion that I don't think you'll be able to do what I think you're trying to do completely externally from the application. You can grab window handles with WinAPIs and do some basic things with that, but not as much as you want. And getting information about DataWindows with WinAPIs? Forget it.
I believe I've heard of an API like the one you're asking about, but I've never heard of anyone other that automated testing software tool manufacturers getting their hands on it. If this is true (and the quality of this information is along the lines of "heard it in the hallway"), I suspect there might be some application security issues in letting this get out. (I know you'd never want to infect my application, or poke around and find out my secrets. grin)
Even with hooks into the PowerBuilder VM memory space, I'm not aware of being able to get a list of objects in memory without some PowerScript framework hooks (e.g. populating a list on every open and constructor with object handles). Once you've got a window handle, you can easily traverse its control arrays (and its subclasses control arrays) to get a list of objects on the window, but things like handles to NVO instance variables would be problematic.
I admire the idea. I wish I had better news (other than maybe Rex might solve your problem without the headaches of doing it yourself). Now I'm looking forward even more to what eran may release! grin
Good luck,
Terry.
I've just created such a tool, but I cheated a bit. Was actually about to ask the same question myself on the PB newsgroups. My solution is made of two parts:
Spy-like tool - a stand-alone app that like Spy++, i.e. lets you drag a target onto a control, using Windows API functions (though written in PB).
Internal infrastructure for target applications - located at the ancestor of all of the application's windows. Once given a certain (windows) handle, it goes through the Control[] array and looks for the control whose handle matches the given one. If necessary, it also recurses into control-containers such as tabs.
When the user selects a control, the spy tool first looks for its containing window using Windows API. When found, the tool sends a custom message to that window, which is then handled by the app's infrastructure. The control is then located in the PB app, and its details are finally sent back to the spy tool, which presents them to the user.
I suspect the infrastructure part can be replaced with some external thing, as I've seen tools that seem to be able to do that (Visual Expert, QTP). However, I haven't had the time to further investigate, and this solution was relatively easy to develop.
I've got to say, your question comes on a surprising timing. See this recent question of mine. If you're interested in the tool I've created, drop me a comment.