• Replies 17 replies
  • Subscribers 0 subscribers
  • Views 77 views
  • Users 0 members are here
Options
3sides - Social sharing widget
Related

Display iSheet Data on Home Page/Wiki

Sean Pillai
27343

I recall that there is a simple way to display iSheet records on a site's home page (or wiki) in a table or single-item format.  I'm referring to data from each individual row as opposed to charts and other aggregate data visualizations.  However, I haven't been able to find the instructions.  Any assistance would be appreciated.  I'm trying to display iSheet data in a more user-friendly manner by, for example, placing the contents of each column in a separate row, with each iSheet row corresponding to a separate table on the home page/wiki.

 

Simplified example:

(1)  This is my iSheet record:

 

Client Name Client Jurisdiction Client Code Client Mailing Address Client Relationship Manager(s)
Acme Co. Delaware 1234567 123 5th Ave., New York, New York Bob Smith; Amy Jones

 

(2)  I'd like to generate the following on the home page/wiki (including a link at the bottom that would allow the user to edit that particular record):

 

Client Name Acme Co.
Client Jurisdiction Delaware
Client Code 1234567
Client Mailing Address 123 5th Ave., New York, New York
Client Relationship Manager Bob Smith; Amy Jones

Edit Record [THIS LINK WOULD TRIGGER AN EDIT OF THE RECORD

 

]]>
Parents

  • Andrew Quinn I was talking about the secret key as well. Every Program, which uses an OAuth2 API needs to have this in its memory (and so somewhat exposed to the user) otherwise it would not get an access_token or a refresh_token.

    My Point is, that HighQ exposes the secret key in this way, and they got a ISO 27001.

    As I said, just try to make a memory dump of HighQ Drive. You will find a secret key there.

    Ryan D'Souza I agree, an attacker would need user credentials to use the secret key. But if an attacker could get a refresh_token, this token would allow them to access HighQ even without user credentials.

    So in the end using the API in the frontend is not entirely risk free, but also not a gaping security hole. Because for an attacker to get the secret key or a refresh_token they would need to find an additional security hole (like XSS or malware on the users machine). And if one of those vulnerabilities is present, the API key in the frontend would be the least of your concerns.

Reply

  • Andrew Quinn I was talking about the secret key as well. Every Program, which uses an OAuth2 API needs to have this in its memory (and so somewhat exposed to the user) otherwise it would not get an access_token or a refresh_token.

    My Point is, that HighQ exposes the secret key in this way, and they got a ISO 27001.

    As I said, just try to make a memory dump of HighQ Drive. You will find a secret key there.

    Ryan D'Souza I agree, an attacker would need user credentials to use the secret key. But if an attacker could get a refresh_token, this token would allow them to access HighQ even without user credentials.

    So in the end using the API in the frontend is not entirely risk free, but also not a gaping security hole. Because for an attacker to get the secret key or a refresh_token they would need to find an additional security hole (like XSS or malware on the users machine). And if one of those vulnerabilities is present, the API key in the frontend would be the least of your concerns.

Children
No Data