Utility.SearchPrincipals does not return any results - sharepoint-2013

I am writing a provider hosted SharePoint 2013 application. I'm using SharePoint online.
Since the people picker isn't supported in this scenario, I need to build my own. I found the SearchPrincipals method. That seems like exactly what I'm looking for, but no matter what I try, the method is returning with 0 results.
What little information I've found around this method suggests that the problem is usually a permissions issue, but the user that I'm logged in as is a Site Collection Administrator (ClientContext.Web.CurrentUser.IsSiteAdmin is true), so that shouldn't be the case with me.
I've tried passing in virtually every combination of PrincipalType and PrincipalSource, even ones that didn't make sense. I've also tried passing in ClientContext.Web.SiteUsers for the scope, and also null, both of which I've seen used in my searches, and that didn't turn up any results either.
Any help would be appreciated!

I figured it out. The ClientContext of the CSOM (Client Side Object Model) allows the developer to make multiple --unrelated -- queries. It queues up these queries and does not execute them until ExecuteQuery is called. Even though SearchPrincipals is a static method off of the Utility class, it still translates the method call into a query and queues it up. The method will always return an empty collection, but once you call ExecuteQuery on the ClientContext, that collection is then filled with the results of the search.
Also, another problem that I ran into immediately afterwards was that I was getting an error that seemed completely unrelated to my query when I called ExecuteQuery. It turns out that there was code that previously executed that queued up some queries, but it never executed them, so when I called ExecuteQuery, it executed those queries as well, and one of those was erroring. If you are getting an unexpected error, it's a good idea to see if there are other queued queries that haven't been executed yet. You can check the boolean property HasPendingRequest to help determine this.
Hopefully this answer saves other people a lot of time!

Related

Django: Making sure a complex object is accessible throughout multiple view calls

for a project, I am trying to create a web-app that, among other things, allows training of machine learning agents using python libraries such as Dedupe or TensorFlow. In cases such as Dedupe, I need to provide an interface for active learning, which I currently realize through jquery based ajax calls to a view that takes and sends the necessary training data.
The problem is that I need this agent object to stay alive throughout multiple view calls and be accessible by each individual call. I have tried realizing this via the built-in cache system using Memcached, but the serialization does not seem to keep all the info intact, and while I am technically able to restore the object from the cache, this appears to break the training algorithm.
Essentially, I want to keep the object alive within the application itself (rather than an external memory store) and be able to access it from another view, but I am at a bit of a loss of how to realize this.
If someone knows the proper technique to achieve this, I would be very grateful.
Thanks in advance!
To follow up with this question, I have since realized that the behavior shown seemed to have been an effect of trying to use the result of a method call from the object loaded from cache directly in the return properties of a view. Specifically, my code looked as follows:
#model is the object loaded from cache
#this returns the wrong object (same object as on an earlier call)
return JsonResponse({"pairs": model.uncertain_pairs()})
and was changed to the following
#model is the object loaded from cache
#this returns the correct object (calls and returns the model.uncertain_pairs() method properly)
uncertain = model.uncertain_pairs()
return JsonResponse({"pairs": uncertain})
I am unsure if this specifically happens due to an implementation from Dedupe or Django side or due to Python, but this has undoubtedly fixed the issue.
To return back to the question, Django does seem to be able to properly (de-)serialize objects and their properties in cache, as long as the cache is set up properly (see Apparent bug storing large keys in django memcached which I also had to deal with)

How could I modify django-tracking2 so users can opt out of tracking

I'm making a website right now and need to use django-tracking2 for analytics. Everything works but I would like to allow users to opt out and I haven't seen any options for that. I was thinking modifying the middleware portion may work but honestly, I don't know how to go about that yet since I haven't written middleware before.
I tried writing a script to check a cookie called no_track and if it wasn't set, I would set it to false for default tracking and if they reject, it sets no_track to True but I had no idea where to implement it (other than the middle ware, when I tried that the server told me to contact the administrator). I was thinking maybe I could use signals to prevent the user being tracked but then that would slow down the webpage since it would have to deal with preventing a new Visitor instance on each page (because it would likely keep making new instances since it would seem like a new user). Could I subclass the Visitor class and modify __init__ to do a check for the cookie and either let it save or don't.
Thanks for any answers, if I find a solution I'll edit the post or post and accept the answer just in case someone else needs this.
I made a function in my tools file (holds all functions used throughout the project to make my life easier) to get and set a session key. Inside the VisitorTrackingMiddleware I used the function _should_track() and placed a check that looks for the session key (after _should_track() checks that sessions is installed and before all other checks), with the check_session() function in my tools file, if it doesn't exist, the function creates it with the default of True (Track the user until they accept or reject) and returns an HttpResponse (left over from trying the cookie method).
When I used the cookie method, the firefox console said the cookie will expire so I just switched to sessions another reason is that django-tracking2 runs on it.
It seems to work very well and it didn't have a very large impact on load times, every time a request is made, that function runs and my debug tells me if it's tracking me or not and all the buttons work through AJAX. I want to run some tests to see if this does indeed work and if so, maybe I'll submit a pull request to django-tracking2 just in case someone else wants to use it.
A Big advantage to this is that you can allow users to change their minds if they want or you can reprompt at user sign up depending on if they accepted or not. with the way check_session() is set up, I can use it in template tags and class methods as well.

Duplicated SignInCookie cookie in IdentityServer3

We started noticing we have two SignInMessages with the exact same id when authenticating using IdentityServer 3. Checking the code, I believe this happens because one gets created on method "CreateSignInRequest" when authenticating, and also here after identityServer3 calls "AuthenticateLocalAsync", if "IsPartialSignIn" is set to false, like in our case, then this line is executed "signInMessageCookie.Clear(signInMessageId);". This clear method, actually does a Cookie.Append, this is (I believe) why we have two SignInCookies.
Has anyone seeing something like this? If so, were you able to figure out how to make it 1. It's not a big deal, but would prefer to keep the headers smaller.

No output from Raven.Client.MvcIntegration.RavenProfiler

I am having no joy with the RavenDb profiler. There's output rendered in the browser, but the profiler always claims there are no requests and no sessions.
When the document store is created I make the following call:
RavenProfiler.InitializeFor(docStore);
And in my master layout I have this, just before the closing body tag:
#Raven.Client.MvcIntegration.RavenProfiler.CurrentRequestSessions()
As far as I can tell there's nothing more required in order for this to work (of course, I may be wrong) yet the output of the profiler is always as above.
I'm using version 3.0.0.0 of Raven.Client.MvcIntegration.
Any ideas?
I figured it out. It was an issue with how I resolved the DocumentStore via my Windsor Container. It turned out that I ended up with two instances of the DocumentStore, and the wrong one was registered with RavenProfiler. Once I ensured that only one DocumentStore was created, everything started working as expected.

Unit test says function was called, but console.logs are not showing up

I have a function inside another function that is supposedly getting called, according to my expect(Parse.User.Login).toHaveBeenCalled() line, but there are some console statements inside the callback to that which aren't showing up.
Is there some type of dependency I'm missing on my unit test causing the callback not to have called? I think it is getting to the server, because it tells me I need a Parse.initialize with the application keys if that's not present.
How do I resolve it?
It just occurred to me, maybe that's something in Parse.js telling me I need the Parse.initialize(keys,keys). I changed the parse keys to nonsense, and its not telling me they're wrong, so it must be that parse isn't being touched at all. No request is being sent to the server.
I've been putting up a few questions about this, but now I guess this can't be done with Karma-jasmine -- at least the way the app is set up right now. It's depending on a web service to give the errors, instead of having an angular directive set up up front to detect the errors in the fields beforehand.
I'm a newbie at this obviously, or I would have recognized this sooner:
This type of testing, where you are depending on responses from the server and that's that, should be delegated to E2E tests.
Meaning, here what am I supposed to test that wouldn't be just hardcoding the desired response right into the jasmine Spy? What would that do to just set the rootScope to a user attribute? Maybe, if state.go changed the view to another page, and then acted on the $rootScope data, this would make sense. But for now, there's no point. I'm not designing the next step, nor do I know what it is at the moment, so I can only sit back.