Exposing verificationToken in built-in user model - Loopback 3 - rest

Subject says it all really. Just trying to figure out how to expose the verficationToken property of the default built-in user model in Loopback 3.
I've tried adding it to the "scope" definition in users.json, it works for other fields but not for verificationToken. I've also made sure to remove it from the "hidden" array in users.json.
I've read the very limited information provided on white-listing here (https://loopback.io/doc/en/lb3/Model-definition-JSON-file.html) and it talks about overwriting the toJSON method of the model, but I'm not seeing much info on how to do that, particularly for a built-in model.
Anybody every dealt with this before? Thanks in advance for any tips you might provide!

To access verification token,If you are using User.json by default it hides the password and verificationToken from accessing in rest api
By Default
"hidden": ["password", "verificationToken"],
change it to
"hidden": ["password"],

Related

core_user_create_user and moodle webservice setup not working

I have done everything needed to setup webservices on my moodle 3.11 instance, including roles/capabilities/user. However sending a test request always gives {
"exception": "dml_missing_record_exception",
"errorcode": "invalidrecord",
"message": "Can't find data record in database table external_functions."
}
The URL to access it is of the format https:///moodle/webservice/rest/server.php?wsfunction=core_user_create_user&service=mymoodleusermanage&moodlewsrestformat=json&users[0][username]=ABC&users[0][firstname]=VPTest&users[0][lastname]=None&users[0][email]=mail#xxx.com&users[0][password]=xxxxx&users[0][auth]=manual&wstoken=xxxxxxxxxxxxxx
The service parameter is correctly set to the shortname of the service. Does the service have to be defined anywhere additionally apart from Site Administration->Server->Web Services->External Services->Custom Services
Thanks for any help that can be given
The answer is very simple - you are trying to call a non-existent webservice function (hence the error message about being unable to find the database record for the function in the external_functions database table).
If you look in the Moodle code: https://github.com/moodle/moodle/blob/master/lib/db/services.php#L1717 you will see that the function is called core_user_create_users - with an "s" at the end of it.
If you add that extra "s" into the URL parameters you are using, then it should work.
https:///moodle/webservice/rest/server.php?wsfunction=core_user_create_user&service=mymoodleusermanage&moodlewsrestformat=json&users[0][username]=ABC&users[0][firstname]=VPTest&users[0][lastname]=None&users[0][email]=mail#xxx.com&users[0][password]=xxxxx&users[0][auth]=manual&wstoken=xxxxxxxxxxxxxx
you must change username all character small letter [username]=ABC like this [username]=abc and add s wsfunction=core_user_create_users

SharePoint REST: Field or property does not exist

I'm using REST to get data from a SharePoint library to display using the DataTables jQuery API. Everything is working fine, but I've got one stubborn field in this library that REST isn't able to grab.
The name of the field is "For", but the internal name is _x0046_or1 (not sure why, I didn't create the library). I've double-checked that this is the correct internal name using REST and by checking the code for my library view in Designer.
So using my REST call:
/_api/Web/Lists/GetByTitle('SAS2')/items?$select=_x0046_or1&$top=5000
And I get back:
The field or property '_x0046_or1' does not exist.
Anybody have any suggestions for a different way to reference this field that the REST api might recognize?
I did as Rohit suggested in the comments, and made the REST call without the select. It turns out that the actual internal name of the For field was "OData__x0046_or1". No idea why.
Thanks for the helpful suggestion, Rohit!
In SharePoint 2013 if you name a field with 3 or less chars and then end it with a number, SP will rename the internal name.

How to represent a read-only property in a REST Api

if you have a REST API that is hypermedia-driven (HATEOAS) you can easily change a client's behavior by including or omitting links in the response (_links). That enables a client to completely forget about testing permissions for the operations that are possible in the current state of a resource (the link to the operation is present or not).
Additionally you can leave out properties in the response if the current user doesn't have permission to see it.
That way authorization is done entirely on the server (and controls actions and properties that are eligible to execute/view).
But what if I want to a have a read-only property? It is no problem for the REST API to ignore the property if it is present in the request (_POST_ OR _PUT_). it just won't get saved. But how can a client distinguish between write and read-only properties to present the user appropriate controls (like a disabled input field in HTML)?
The goal is to never ever have the client request a user's permissions, but to have a completely resource driven client/frontend.
Any help is greatly appreciated :-)
If I misunderstood your question, I apologize upfront. With that being said...
But how can a client distinguish between write and read-only
properties to present the user appropriate controls (like a disabled
input field in HTML)
Well, there are multiple solutions to this. The simplest one I can personally think of is to make each property an object having a simple structure of something like:
...
someProperty: {
value: 'some value',
access: 'read-only'
},
someOtherProperty: {
value: 'some value',
access: 'write'
}
...
You can obviously get as creative as you want with how you represent the "access" level of the property (using enums, booleans, changing access to be isReadOnly or whatever).
After that, the person using the API now knows they are read-only or not. If they submit a "write" value for a "read-only" property as part of the POST payload, then they should expect nothing less than a 403 response.
Edit:
In case you can't alter the properties in this manner, there are a number of other ways you can still achieve this:
write documentation that explains what access each property has
create a route that the user can submit 1 or more properties to in order to receive a response that indicates the access level of each property (response: { propName: 'read-only', propName2: 'write', etc.)
Return a propertyAccess map as part of the response (mapping properties to access levels).
end of the day, you just need a way to map a property with an access level. however that's done depends on what your restrictions and requirements are for the api, what changes you can make, and what is acceptable to both your client(s) and the business requirements.

How to access information in Sails after creation?

I was wondering what happens in Sails when you pass information in through the URL. For example, if you were to type:
localhost:1337/project/create?Id=2&Name=John
how does Sails create that into a model? I need to be able to take the name and pass it to separate database, but I have no idea how to access the information (such as name=John, in this case) after each creation.
Thanks, I appreciate it!
Under your api/models/project.js file you can override afterCreate method like doc say :
afterCreate: fn(newlyInsertedRecord, cb)
More here : http://sailsjs.org/#!/documentation/concepts/ORM/Lifecyclecallbacks.html

fiddler - can I output requesting client ip/name?

Using the code here shows how to add a column:
http://fiddler2.com/documentation/KnowledgeBase/FiddlerScript/AddColumns
What I'd like to know, though, is the ip (or name) of the client issuing the request. Is that possible to determine?
Thanks,
Ben
I believe you can grab this off Session object that is passed in. So in the code example in the article you link to you would set the value of you column to oS.clientIP.
For convenience the complete code you have to insert into the Handlers class:
public static BindUIColumn("ClientIP")
function ColClientIP(oS: Session){
return oS.clientIP;
}
This is now available from the UI using Customise Columns and the session flag X-clientIP. Now means V5.0.20211 of Fiddler Classic. Probably been there for some time.