I'm using fusion tables with an android app that I'm developing in AppInventor, and I had a question about the SQL Query for updating a row.
Now, before I ask the question, I will let you know that I would have included some screenshots of my blocks-editor code, but my boss told me I had to keep the app 100% closed source, so I can't provide any. Hopefully I'm not being too vague.
Anyways, I set a FusionTablesControl query using the "make text" block and the Google API UPDATE query, but when I send the query on my test device (Samsung Galaxy Player 5), the overlaying "Fusion Tables" load screen pops up for only a split second (it normally shows for 2 or 3 seconds). When I check the tables, there has been no change.
I think syntax is still a potential problem because when I typed the encoded URL into google chrome's address bar, it still didn't update the table. Here is the basic syntax of what I typed into the address bar.
https://www.googleapis.com/fusiontables/v1/query?sql=UPDATE%20tableID%20SET%20(Column1%3Ddata1%2C%20Column2%3Ddata2%2C%20Column3%3Ddata3%2C%20Column4%3Ddata4)%20WHERE%20ROWID%20%3D%20%27rowID%27
The decoded URL after the "sql=" part is:
UPDATE tableID SET (Column1=data1, Column2=data2, Column3=data3, Column4=data4) WHERE ROWID = 'rowID'
Any help would be appreciated.
Also, is it possible to set Google's API response to CSV instead of JSON?
Thanks,
~T16626
This does not work like that, because you did not use authentication. More about that see here:
Identifying your application and authorizing requests
Every request your application sends to the Fusion Tables API needs to
identify your application to Google. There are two ways to identify
your application: using an OAuth 2.0 token (which also authorizes the
request) and/or using the application's API key. Here's how to
determine which of those options to use:
If the request requires authorization (such as a request for an
individual's private data), then the application must provide an OAuth
2.0 token with the request. The application may also provide the API key, but it doesn't have to. If the request doesn't require
authorization (such as a request for public data), then the
application must provide either the API key or an OAuth 2.0 token, or
both—whatever option is most convenient for you.
To access a fusion table with App Inventor, you have 2 possibilities:
use the built-in fusiontable control blocks, how to set up everything for App Inventor please see the Pizza Party tutorial
use the web component with authentication, for details see here
Related
I am currently learning to make DRF APIs for something I am working on. I was wondering how exactly I would secure the API POST requests I send via the client side?
For example, let's say I have a log in form where the user can enter their information, this information needs to be send to (or POST-ed to) my API for verification. I do not want just anyone sending requests to the server and so, I would want to use an API key but since this is being done on a website, anyone could see the API key if they wanted to, and then exploit the server by sending a ton of requests.
My current idea is to use serializes in DRF to check if the API POST request has everything it needs but I am fairly certain this can be easily found by checking what sort of JSON my code sends to the server, so how exactly do I go about securing this such that I can send the information to the bare domain (like http://127.0.0.1:8000) and then have code which can accept that information?
I apologize for any confusion, if it is confusing. Let me know if you need any clarification.
If you are creating API any one can send request to server. same goes for website and webpage. Their is no way you can avoid this. But their are ways to handle possible misuse.
like using CAPTCHA for login form which can be filled by one on the web. though wrong CAPTCHA text can be send by anyone you must check it on server for their correctness. or use google reCAPTCHA like services for outsourcing this task.
API key should be given after login NOT before login. and if it is given after successful login then the key is obtained by legitimate user which can obviously do whatever he is allowed to do on website. their should not be problem in that.
further explanation to the question will lead to details of denial-of-service i.e DOS attack. you should consult expert on that field if your application requires to handle DOS attack.
I'm implementing the Socrata API to be able to parse publicly-available data from the City of Chicago open data set. I am really just concerned about the data itself, so I did not initially think that I would need to implement OAuth2 through an app exposed via ngrok to be able to GET the data.
My initial attempt was to take the GET requests mentioned in their documentation and try to get responses through Postman.
Here's an example of such an attempt:
I also added my Socrata App Token as a param in the querystring, but the same message was shown.
So I tell myself, ok, maybe they deprecated GET requests without making the client go through OAuth2. If they didn't deprecate these GET requests, I would prefer not to have to deal with OAuth2, but I began implementing the authentication process and everything went successfully until I got to the following instructions found here:
I have every single value that needs to be included in that POST request except for 'authorization_type'. Where does this come from? I tried leaving 'authorization_type' in as a string, but received a response similar to the 'Invalid username or password' message in the top image in this question.
Are you only accessing public datasets from Chicago's data portal? From your screenshot it looks like you're trying to access the Building Permits dataset, which is public.
Authentication is only required for modifying datasets or accessing private data, so chances are very good you don't even need to authenticate. Just include an application token with your request for throttling purposes.
Glad to help you figure out your OAuth workflow, but it sounds like it might be unnecessary.
I'm trying to figure out how Likeboost or LikeHero work, 'cause I believe Instagram doesn't allow you to use Like endpoint to add a like to an image and they require you to submit the app for review as they stated here:
To request access to this endpoint, please complete this form.
But these apps just ask for your username and password (Surprisingly you don't get transferred to Safari for authentication process) and then you could like an image from that particular app. How do they do that? Isn't this against the following paragraph?
The ability to POST and DELETE likes, follows and comments is restricted to applications that offer business services and not consumer facing apps.
That applications that you are mentioning are using a fake native login page in order to avoid you leave from the application (like #Matthew Antolovich said). Once they get the access_token, there are no more dificulties and they can use the API calls.
As you can see in the Authentication documentation they might be using the Client-Side (Implicit) that is less secure but it works for they purposes.
They are giving permissions only to trusty applications in order to avoid that fake applications (bot apps, fake users, ...) use some API functionalities.
If you want to use these calls, you should fulfill the form that they are giving to you once your application is finished. If you are still developing the application you have to trust the Like documentation without the capability of test if it works.
There are other ways to restrict apps to use some calls (limit of requests per day, ...) but this is how they are doing it so, we must adapt.
Like #Matthew Antolovich said in his comment, if those apps are asking you for your user and password, they can log-in using the same requests present on the web. They could (and probably are) make their own API by reverse engineering the http requests.
On a side note, I would personally never trust those kind of apps.
The title is a bit obscure. I'm interested about some feedbacks on a specific architecture pattern.
Let's take as an example the Stripe API: when you are using this API, the system is basically broken into two parts: live mode and test mode. If you hit the "/customers" end-point, you can either retrieve test mode customers or live mode customers, based on the type of API key used.
I'm asking myself how I could implement such a pattern using an OAuth 2 access token.
In my workflow, I have a single application page (JavaScript) that communicates through my API. I have a "live"/"test" switch, so basically my whole website is replicated into two distinct environments.
When I log in into my application, my authorization server creates a unique access token (OAuth 2 Bearer token), that is send for each requests. But obviously, my access token is tied to the "session", not an "environment" (live or false), so if I want to implement a switch live mode / test mode, I cannot rely on the token, because the token is "generic".
I've thought about two options:
Depending on live mode or test mode, I send an additional header to all my request (like X-Livemode which is either true or false). Then, in my back-end, I reuse this header to automatically adds a filter on all my requests.
If I switch to live mode or test mode, I ask my authorization server another access token. This would means that access token would have additional context information. However this seems a bit complicated, and I'm not sure that OAuth 2 spec allows token to have such additional information.
I'm not sure if this post is clear or not :p.
The second part of the question, is what is the best way to implement such a system where all the resources are basically duplicated between live / test mode ?
In my understand, it should be as simple as adding a "isLivemode" property to all resources, and make sure that all my SQL queries are aware of this. Is this correct?
Thanks!
A much simpler solution I've used in the past (albeit a bit of a workaround) is just to append "live" or "test" (base64 or hex encoded) to the api key, like so:
Imagine your actual key is:
9a0554259914a86fb9e7eb014e4e5d52
In your key presentation, present your key to the user as:
9a0554259914a86fb9e7eb014e4e5d526c697665
Then use a regular expression to strip off the known characters.
Alternatively, if you're equipped to handle key-value maps, a more "OAuth2-spec" approach would be to generate unique keys for live and test and do a key-value map lookup on the request to determine if one belongs to live or test.
I'm trying to get access to the Google's todo feed with this url:
https://www.google.com/calendar/tdl?secid=<SECID>&tdl={%22action_list%22%3A[{%22action_type%22%3A%22get_all%22%2C%22action_id%22%3A%221%22%2C%22list_id%22%3A%2215052708471047222911%3A0%3A0%22%2C%22get_deleted%22%3Afalse}]%2C%22client_version%22%3A-1}
If I open this in my browser with a correct secid, it shows me right what I want.
Now, the question is: how do I get secid programmatically (specifically, in a java program)? I have access to the authToken (from CalendarService), but I have no clue how to use it to authorize my access to the URL above.
I tried to use the url http://google.com/accounts/ServiceLogin, but I didn't find any examples.
Any help, please?
From what I read secid is a session ID obtained from browser's cookies. Whereas your case uses Java which implies a server app. If that is the case, you want to drop the idea of using secid entirely.
Instead, you want to check out Google's OAuth2 documentation. If you are using Java, most likely you would be interested in the web-server OAuth flow. Pay special attention to the sequence diagrams.
The key steps include:
1) Obtain an authorization code from Google OAuth with the user's consent. For that, you redirect the user to Google with the appropriate scope. Check the list of calendar scopes for your case. Once the user consents, Google redirects back to you with an authorization code.
2) Call Google OAuth with the authorization code and your app's credentials to exchange for an access token.
3) Call Google's Calendar API using the access token.
And if you use Google's Java client as suggested by #ChaosPredictor, chances are some of the steps are already wrapped into the Java client (and your code will be much simpler).