I'm currently trying to understand how custom credential providers are made.
I have a sample to help me. This sample especially implements ICredentialProvider and ICredentialProviderFilter for WinLogon.
My job is to implement the CPUS_CREDUI usage scenario.
However, there is a lot of things i don't get in the initial implementation so i can't even expect to do my own implementation.
All the documentation i found only explains what each part actually do. Which is the only part 'clear enough' in my mind.
The problem is that i can't connect those parts together.
The different functions seemed to be called by Windows itself. How can i know what's the caller, which parameters are used, this kind of things ?
If i knew, i might have a better understanding of the whole process.
For example :
There is a recurrent parameter of type CREDENTIAL_PROVIDER_USAGE_SCENARIO which seems to change the way the CP is initialized further in the code.
It seems to be first defined in the CredentialProvider constructor but since i don't know what the caller of the constructor is...
I'm guessing it's called by WinLogon but if so, what actually define the parameters ?
The logs of the sample always show this parameter value as 'CPUS_LOGON'.
If this is a consequence of the CP constructor being called by WinLogon (If my previous hypothesis is true), how does CPUS_CREDUI can be called since it's post Logon ?
That's the main questions i have so far. Thank you if someone can unlight me.
I'm also open for every additional informations you would have for me.
Have a look at Microsoft's docs
One of the first calls to your credential provider will be SetUsageScenario
HRESULT SetUsageScenario(
CREDENTIAL_PROVIDER_USAGE_SCENARIO cpus,
DWORD dwFlags
);
The first parameter is scenario.
If your provider is not designed for the provided scenario you can just return E_INVALIDARG.
Related
I am using the InjectTouchInput() API on Windows 10 to inject touch events from a separate digitiser. That works well (multi-touch etc.). There are quite a few examples out there of using the API for that, i.e. using a pointer type of PT_TOUCH, including one from Microsoft, so it wasn't too difficult to customise them to my needs.
However, I have not found any example of using other pointer types, especially PT_PEN - which I need when the digitiser gives me pen inputs. (I'd also be interested in PT_MOUSE, mainly to avoid having to use SendInput() or mouse_event().)
Whenever I call InjectTouchInput() with PT_PEN, it fails with ERROR_INVALID_PARAMETER. I've tried quite a few combinations of fields to set, but nothing (so far) works. The MSDN documentation doesn't describe what to do for PT_PEN (it doesn't describe much for PT_TOUCH, but at least there's one sample), so it's quite difficult to know what fields should be set, which ones should be ignored, any specific sequence of operations, etc. I've been scouring the net, but couldn't find any example of PT_PEN use.
Does anybody have sample code or know where to find any, knowledge of where useful documentation is located, or knows how InjectTouchInput() is supposed to be used for PT_PEN (and PT_MOUSE)?
It turns out that InjectTouchInput() is indeed only for touch inputs - not pen, mouse, or generic pointer.
You might say that it's obvious, since you pass an array of POINTER_TOUCH_INFO entries to the API, but confusion arises because the documentation for POINTER_TOUCH_INFO (and all subsequent documentation) is describing the contents mostly as seen from someone who interprets contents he is given, and not content he is trying to set, and POINTER_INFO (the first element in POINTER_TOUCH_INFO) can specify a pointer type of PT_POINTER, PT_TOUCH, PT_PEN, PT_MOUSE, or PT_TOUCHPAD, so it feels kinda natural to think "wait, I can inject all these different types of pointers!"
Of course, all the pointer types, despite having POINTER_INFO in common, takes slightly different parameters. For instance, there is orientation and pressure for PT_TOUCH (in POINTER_TOUCH_INFO), but tiltX, tiltY, rotation, and pressure for PT_PEN (in POINTER_PEN_INFO); but it would be easy to determine which info is relevant given that the pointer type is always the first field in the structures.
Can InjectTouchInput() take POINTER_PEN_INFO entries instead of POINTER_TOUCH_INFO ones? No, it can't - I tried, just in case it would work.
It seems like a missed opportunity by Microsoft to make the API more generic from the start and accept all the supported types of pointers, rather than be limited to touch inputs. At the very least, pen injection should have been straightforward, given that there is a POINTER_PEN_INFO structure (I haven't found structures for the other pointer types besides POINTER_TOUCH_INFO).
Half-way through this thread from 2014 is the mention that "there is no [...] API for pen injection", and things haven't improved since then, so a driver for pen injection is still required. Having said that, the Windows UI Automation API can apparently inject all pointer types (and a game pad to boot), but that's only supported from Windows 10 Anniversary Edition (and I haven't tried it).
We can implement pen input injection with InputInjector.InjectPenInput
And there is no public apis in win32 for pen injection. If your system is Windows 10, version 1809, InjectSyntheticPointerInput can be used.
How can I detect incompatible API changes in C++? (not ABI but API changes)
Where compatible changes are things that can't break compilation of code using the API like:
parameter(s) added to method with default argument
methods added to a class
members added to a class
classes added
order of members or methods changed
comments/documentation changes
And incompatible changes are things that potentially break compilation of code using the API like:
removed arguments, (public/protected) methods, members, classes
type changes of arguments or members
name changes of public/protected members or methods
classes moved from one header to another
OP is right to think that C++ parsing is probably necessary. Likely deep reasoning, too.
I think the way to pose the question is,
for a particular set of uses of an API in an existing application, does changing the API change or break of the application?
If you don't limit yourself to a specific set of uses, almost any change to an API will change its semantics. Otherwise, why would you make them (modulo refactoring?). And if you use the full set of API features in the application, then its semantics must change somehow too.
With a specific set of uses, one can arguably determine which properties of the API might affect the specific uses, and determine if in fact they do. Ultimately you have to parse the original code accurately to determine the specific set of uses and the context in which they are used. You also have to determine the semantic properties on which the existing application depends, including the properties provided by the legacy API. Finally, you need to determine the properties defined by the new API, and verify still support the needs of the application.
In general, you need a theorem prover over the program properties to check this. And, while theorem proving technology has advanced significantly over the last 50 years, AFAIK said technology isn't strong enough to take generally arbitrary program properties and prove them, let alone overcome the problem of reasoning about arbitrarily complex programs.
Consider:
// my application
int x=0;
int y=foo(x); // API ensures that fail...
if (y>3) then fail(); // shouldn't happen
exit();
// my legacy API
int foo(int x) { return x+1; }
Now imagine the API is changed to:
// my new API
int foo(int x) { return x+2; }
The application still functions correctly.
How about:
// my new API
int foo(int x) { return TuringMachine(x); }
How are we going to prove that TuringMachine(x) produces a value < 3?
If we can't do this for such tiny programs, how are we going to do it
for ones that we write in practice?
Now, you might be able to limit the set of changes you will consider to
simply "syntactic" operations, such as "move method", "add parameter with initial value", etc.
You'll still need to parse the original program and modified APIs, and check that the syntactic properties imply semantic properties that don't damage the original program. You'll likely need control and dataflow analysis, alias analysis to worry about pointers, etc, and the tool will at best be able to tell for a limited number of cases when no change has occurred.
I'm sure there are research papers on this topic. A quick check at scholar.google.com didn't find anything obvious.
See "Source Compatibility" tab of the report of the ABICC tool. Most of the mentioned API changes and API breaks are detected by this tool.
There are two approaches to use the tool. Original via analysis of header files and a new via analysis of the library debug info ([1]). Use the second one. It's more reliable and simple.
You can find some report examples here: http://abi-laboratory.pro/tracker/
Tutorial: https://sourceware.org/glibc/wiki/Testing/ABI_checker#Usage
The function seems to be quite isolated. Meaning, it is invoked with no args so unlike other functions on Route, it does not have 'easy' access to the 'the model and/or controller' for the route.
The API tells you 'when' this function is invoked, but not much about what you are meant to do in it.
I realize that you can use functions like this.controllerFor, but that seems like it violates what ever type of encapsulation is attempting to be enforced in the activate method, meaning if you were supposed to have access to the controller, it would have been passed as an argument to the function.
If anyone can provide some guidelines for best practices on use of this function, I think it would be helpful to the community.
activate is called once when the route is created for the first time, it's a good place to setup properties that only need to be setup once when the route is created.
setupController is called every time the route is hit (with the controller/model). It is a good place for setting up properties that must be generated each time the route is hit.
http://emberjs.com/blog/2013/02/15/ember-1-0-rc.html
I'm having a bit of difficulty passing a reference type between webservices.
My set up is as follows.
I have a console application that references two web-services:
WebServiceOne
WebServiceTwo
WebServiceOne declares the details of a class I am using in my console application...let's call it MyClass.
My console application calls WebServiceOne to retrieve a list of MyClass.
It then sends each MyClass off to WebServiceTwo for processing.
Within in the project that holds WebServiceTwo, there is a reference to WebServiceOne so that I can have the declaration of MyClass.
The trouble I'm having is that, when I compile, it can't seem to determine that the MyClass passed from the console application is the same as the MyClass declared in WebServiceOne referenced in WebServiceTwo.
I basically get an error saying Console.WebServiceOne.MyClass is not the same as MyProject.WebServiceOne.MyClass.
Does anyone know if doing this is possible? Perhaps I'm referencing WebServiceOne incorrectly? Any idea what I might be doing wrong?
My only other option is to pass each of the properties of the reference type directly to WebServiceTwo as value types...but I'd like to avoid that since I'd end up passing 10-15 parameters.
Any help would be appreciated!
I had a chat with one of the more senior guys at my work and they proposed the following solution that has worked out well for me.
The solution was to use a Data Transfer Object and remove the reference to WebServiceOne in WebServiceTwo.
Basically, in WebServiceTwo I defined a representation of all the value type fields needed as BenefitDTO. This effectively allows me to package up all the fields into one object so I don't have to pass each of them as parameters in a method.
So for the moment, that seems to be the best solution...since it works and achieves my goal.
It's likely that I didn't explain my question very well...which explains why no one was able to help...
But thanks anyway! :-)
Move the types to a separate assembly and ensure that both services use this. In the web service reference there is probably some autogenerated code called Reference.cs. Alter this to use your types.
Edit: To reflect comments
In that case take the reference.cs from that web service you cannot control use it as the shared type.
Your error message explains the problem. The proxy class on the client side is not the same type as the original class on the server side, and never will be. Whether it's a reference type or a value type is irrelevant to how it works.
I don't quite understand what your exact problem is, but here are a few guesses:
If you are trying to compare two objects for equality, then you will have to write your own compare function that compares the values of each significant property/field in turn.
If you are trying to copy an object from one service to the other, then you will have to write your own copy function that copies the values of each significant property/field in turn.
If you were using WCF, you would have the option of bypassing all this and just sharing one class definition between the client and both services.
Continuing from this question, i am confused whether DISPID_VALUE on IDispatch::Invoke() for script functions and properties (JavaScript in my case) can be considered standard and reliable for invoking the actual function that is represented by the IDispatch?
If yes, is that mentioned anywhere in MSDN?
Please note that the question is about if that behaviour can be expected, not what some interfaces i can't know in advance might look like.
A simple use case would be:
// usage in JavaScript
myObject.attachEvent("TestEvent", function() { alert("rhubarb"); });
// handler in ActiveX, MyObject::attachEvent(), C++
incomingDispatch->Invoke(DISPID_VALUE, IID_NULL, LOCALE_SYSTEM_DEFAULT,
DISPATCH_METHOD, par, res, ex, err);
edit: tried to clarify the question.
It should be reliable for invokes on objects from scripts if the script defines it consistently. This should be the case for JScript/Javascript in MSHTML, but unfortunately there is really sparse documentation on the subject, I don't have any solid proof in-hand.
In my own experience, a Javascript function passed to attachEvent() should always be consistent- an object received that is a 'function' can only have one callable method that matches itself. Hence the default method is the only one you can find, with DISPID 0. Javascript functions don't ordinarily have member functions, although i'm sure there is a way for this to be possible. If it did have member functions, you would see them the same way as member functions on objects. Member functions in JScript will always be consistent with regard to IDispatchEx, according to the rules of expando functions, as any functions added to an object count as expandos.
IDispatchEx interface # MSDN
The default method or property that DISPID_VALUE invokes should be consistent for a given interface. That method/property has to be specified as DISPID_VALUE in the definition of the interface in the IDL for the type library. The only way it could change is if the owner of the interface released a new version of the interface that changed which method/property was the default but that would violate a fundamental rule of COM interfaces.
As meklarian said, DISPID_VALUE (0) seems to work pretty consistantly for JS functions (thus it works great with a custom attachEvent). I've been using them this way for about a year, and it's always worked. I've also found with an activeX control embedded with an <object> tag that to get it to work consistently, I need to implement IConnectionPointContainer and IConnectionPoint for the main (object tag) IDispatch-implementing CComObject, but any others that I expose to javascript as return values from methods or properties (through Invoke) I have to implement attachEvent and detachEvent myself.
When using Connection Points, the IDispatch objects in question will expect events to be fired to the same DISPID as they are attached to on your IDispatch object..
see http://code.google.com/p/firebreath/source/browse/src/ActiveXPlugin/JSAPI_IDispatchEx.h for an example of implementing the ConnectionPoints.
You can add DISPID's to a DISPINTERFACE, but you cannot change them once it has been published. If you need to, you can use IDispatch::GetIDsOfNames to map names to DISPIDs.
Pick up a copy of Inside Ole (2nd ed) and Inside Ole 2 (2nd ed) for a few bucks used on Amazon. It's a good reference for these obscure OLE incantations.