I'm trying to run a query that retrieves a specific set of users from the User table and presents them to a given logged in user, using the Parse JS SDK.
At first I was running a query like:
(new Parse.Query(Parse.Object.extends("_User"))).containedIn("objectId", [/* list of user ids */]).find(/* success & error blocks */);
but then I learned the more correct way was:
(new Parse.Query(Parse.User)).containedIn("objectId", [/* list of user ids */]).find(/* success & error blocks */);
But even with this, I would get back an empty list. I double-checked the db and made sure the ids I was passing were in there, and they were. Just for the hell of it I tried:
(new Parse.Query(Parse.User)).find(/* success & error blocks */);
And I got back the user object corresponding to the current user. So it seems my User queries are only able to access the current user. I also noticed that when I tried running an equivalent query from the Parse API Console, I got the same results! Is this some sort of global setting, or am I doing something wrong? Thanks!
I believe you have to use CloudCode due to User Security Settings in Parse. Try shifting this to a cloud code function and include
Parse.Cloud.useMasterKey()
prior to the cloudcode function. This is a security 'feature' of Parse to ensure people can't edit and access other user profiles and information.
See Parse security site here:
https://parse.com/docs/js/guide#security-object-level-access-control
and more on use and considerations of implementing useMasterKey() and its persistence.
https://parse.com/docs/js/guide#security-implementing-business-logic-in-cloud-code
I would recommend not condensing all these calls into one line for the sake of saving lines. It sacrifices readability. Although, it's technically not wrong, and the docs even say the calls return a query so you can chain calls, so to each their own.
I don't see anything wrong with your call, though. How are you accessing the retrieved objects? What is the list of objectIds that you are passing into containedIn? We need a bit more of your code here, I think.
edit - I would say I'm 80% sure, without more information, that this is an ACL / CLP issue. Go to the dashboard, hit the _User class, press Security, and see what the read/write settings are.
Looks like a CLP issue to me. Maybe Find permission on your User class is disabled. Go to your User class, tap on security, switch to advance and then check whether the Find permission is ticked off or not.
Related
I'm totally confused.. I finally got the SuiteTalk API working and am able to make authenticated calls from my JS server..
I'm calling the GET /invoice route, which documented here:
https://system.netsuite.com/help/helpcenter/en_US/APIs/REST_API_Browser/record/v1/2022.2/index.html#tag-invoice
Says that it should return to me an InvoiceCollection which is a collection of Invoices which, by the documentation, has all the fields I need as part of an Invoice.
However, the actual response I am getting back is just an array of items that only has the ID in it.. where are all the other invoice fields?!
I tried to just fire off subsequent calls to the /invoice/{id} route with each ID, but I am getting back some of them as unauthorized and some not.. assuming having to do with timestamp being to close together or something.
There has to be a way to call up to /invoice and get all of the data having to do with an invoice and not just the ID right?
I'm also wondering how I can utilize the "Q" param to filter to invoices only for a certain customer, or date, etc. Appreciate any help!
I recommend trying all these queries in postman (netsuite provides a collection for it). If you try it there, you'll see that {{REST_SERVICES}}/record/v1/invoice returns a list of id's and links to invoices.
If you dont see the details of an invoice, can that have something to do with the rights (to that subsidiary)?
e.g. GET: {{REST_SERVICES}}/record/v1/invoice/164198 shows me the entire record.
To get invoices from a certain customer i think i would go for a query in the suiteql restlet.
Hope that helps a bit. I'm just discovering suitetalk myself and it's not the easiest to get a grip of.
I was looking at another question's answer regarding changing the userId from the client side and following along but not getting expected results;
Meteor.userId is changeable
I followed steps 1 through 5 just fine with no issues but then set the userId() to the user I'd just logged out in a separate browser using Meteor.default_connection.setUserId('usersfjhjdskfh');
Rather than display a spinny in place of the email address since the server shouldn't be returning data, it displayed the actual user's email address I'd used there. (It did not however, bring back the party information and show it on the map).
Is this intended behavior and I missed the point of the last answer given back in December or has something changed? (I'm running Meteor 0.6.2 and both insecure and autopublish were removed from my example)
Im assuming you want to change the user's _id and not change the logged in user via an id. To change the user id you could probably do something like
Meteor.users.update(Meteor.userId(), {$set:{_id:<new Id>}});
Assuming you have the correct permissions in place with Meteor.users.allow. This should change the _id of the current logged in user.
The previous question demonstrated the security when changing local client side Meteor functions and how it would affect the server. The Meteor server doesn't trust anything from the client and double checks it with the allow/deny rules before changing it whatever the data may be for that current logged in user. So the user does need to be logged in to change any data about them on the mongodb database on the server for the allow/deny rules to comitted.
I'm working on a search function for my Web app (HTML, JS & CSS only). I'm using jQuery's .getjson() method to retrieve data from a feed and display those results on a page. Inside of an .each() statement I'm adding HTML markup to the results making some of the elements links to outside sources.
The issue is when a visitor initiates a search on my Web app and clicks on a link from the results to an outside page, then uses the Back button on the browser to go back to the results page, all of the search results are cleared and another search needs to be initiated.
I'd like to temporarily save the search results so if a user clicks on a link from the results, then presses the Back button to come back to the app, all of the results will be available without the new for another search.
Taking this one step further, it would also be cool is the results for past searchs also persists so if the visitor continues to press the Back button, they can see all of their previous searches (with a given limit of course).
HTML5 sessionStorage seems to be ideal for this, but the information that I found points to a tedious coding solution. Can't I just save all of the json results as a JS object and have them re-rendered by my each statement when the visitor presses the Back button? I'm definitely open to using a code library or plugin for this problem.
http://brian.io/lawnchair/ is a good little library for API for persistence. You can use the same syntax as an abstraction for different storage options http://brian.io/lawnchair/adapters/
You have two ways to approach this issue, one is caching the results on your server and populating the view on-demand, and number two is like you previously mentioned - use sessionStorage. sessionStorage (IMO) has a very straightforward API. You can either use sessionStorage.setItem(key, value) or sessionStorage.getItem(key) -- other methods are available as well such as sessionStorage.key(index), sessionStorage.removeItem(key) and sessionStorage.clear(). It would probably be useful to include a cross-browser polyfill solution for sessionStorage, you can check out the "Web Storage" polyfills section at Modernizr: https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills -- Have fun :-/
Off the top of my head:
Every time the user searches, change the hash in the url to a unique string (e.g. 'search-{userInput}' ... you could of course just forget about the 'search-', but I like my urls in pretty). This should give you back-button support. Then:
Alternative A:
Listen for the hashChange Event, parse the window.location.hash and resend the request to your search URL. Theoretically, unless adding the timestamp to the URL or crazy stuff like that, the caching mechanism of your browser should kick in here. If not, it means an additional request, but that should be ok, shouldn't it?
Alternative B:
Extend your existing search query mechanism by caching the results to localStorage (just don't forget to JSON.stringify it beforehand and use a something-{timestamp} key). Then listen for the hashChange Event and pull the results from your localStorage. Personally, I wouldn't recommend this solution as you're clogging up the localStorage (afaik there's a limit at 2.5mB for some browsers).
You're probably going to have to find ways to circumvent missing browser support for at least the hashChange Event, JSON stringify/parse and LocalStorage, but I'm optimistic that there are enough libs/plugins out there by now.
You think too complicated: your search form most likely does not change the url! Use GET instead of POST and you have the desired result. Right now the browser has no way of knowing which state of the website you want to show and by default shows the first - the empty search form
Caching could be added as suggested, but that really is not the problem here
My application implements a custom like button using Facebooks offical built-in like action.
The only missing piece is to disable the button if the user has already liked the resource. After testing various approaches using FQL which were all unsuccessful, I've just tried to issue a get request against https://graph.facebook.com/<user_id>/og.likes which lo and behold returns the Open Graph likes of the current user.
Unfortunately I cannot seem to find a way to filter the result for a specific object_id. Can anyone recommend a solution or knows a way to accomplish the same using FQL? Be advised that we are talking Open Graph Likes here which seem to differ from the standard likes created using the Facebook Like button.
I've also been struggling to know how to get information about these og.likes using the graph API or FQL. They don't seem to be stored in any of the usual tables (url_like, or link_stat). This may not be the "right" way to do it but here's how I do it.
In order to check if the user has liked the object, I am hitting the Graph API as you mention, with the URL graph.facebook.com/[userid]/og.likes. Then I just loop through the array in the response, and look for one that matches the URL or ID of the object that I'm interested in. It's not particularly efficient if the user has a lot of og.likes, but it gets the job done.
I am not sure whether API is available or not.
But, you have workaround. As you know the resource that is being viewed, you know the user id, when ever action gets posted, store that in your db and use that info to disable like.
I will keep you updated, once I find more info.
EDIT
An FQL table containing the Open Graph URLs that a user has Liked.
To read the url_like table you need
user_likes permissions for all Open Graph URLs liked by the current
session user friend_likes permissions for all Open Graph URLs like by
friends of the current session user
source: user likes
Looks like you can set a Like button for your URL then check if a user liked it by ANDing "url=" in the WHERE clause:
https://api.facebook.com/method/fql.query?query=SELECT url FROM url_like WHERE user_id = me() and url="http://www.yourUrl.com"&access_token=...
Note that the url has to be in "quotes"
I'm debating the best way to propagate fairly complex permissions from the server to an AJAX application, and I'm not sure the best approach to take.
Essentially, I want my permissions to be defined so I can request a whole set of permissions in one shot, and adjust the UI as appropriate (the UI changes can be as low level as disabling certain context menu items). Of course, I still need to enforce the permissions server side.
So, I was wondering if anyone has any suggestions for the best way to
maintain the permissions and use them in server code
have easy access to the permissions in javascript
not have to make a round-trip request to the server for each individual permission
Thoughts?
If you have a clear set of permissions, like a "user level" or "user type", you could just pass the value down in a hidden field and access the value through the DOM. You could still do this if your permissions were more granular, but you would either have a lot of hidden fields or you would have to encode the information into XML or JSON or some other format.
You might set them as bit flags so that you could OR a single numeric value with a mask to see if the user had the permission for a specific activity. That would be very flexible and as long as you don't have more than 32 or so specific "rights", that would allow for any permutation of those rights in a very small package (basically an unsigned int).
For example:
0x00000001 //edit permission
0x00000002 //create new thing permission
0x00000004 //delete things permission
0x00000008 //view hidden things permission
.
.
.
0x80000000 //total control of the server and everyone logged in
Then a user with a permission of 0x000007 could edit, create, and delete, but nothing else.
In either case, I think you're on the right track - make the request once per page invocation, store the permissions in a global JavaScript data structure, and go from there. AJAX is nice, but you don't want to query the server for every specific permission all over your page. You would do it once on the page load, set up the presentation of your page and save the value in a global variable, then reference the permission(s) locally for event functions.
If you transmit the permission structure to the client as a JSON object (or XML, if you prefer), you can manipulate that object with the client-side code, and send it back to the server, which can do whatever it needs to validate the data and persist it.
I don't necessarily see it as the most "correct" solution, but would it be possible to keep all the permission stuff on the server side, and just serve the updated UI rather than some kind of JSON permissions system?
You'd have to make the decision based on how busy and intensive your app expects to be, but definitely a decision worth making either way
Encode them as JSON.