I am converting a page to google AMP and need to access cookies to set a view of a division. I am thinking of creating an API for this.
The API will just return all the cookies available on my domain in JSON format. I will hit the API using <amp-state> component and store the returned JSON. Then will take actions according to this state.
Is this a valid approach to use in AMP? Is there any security flow in this?
Using amp-list is the right approach in this case. amp-list makes a request to your server, which can read the cookie and return an appropriate JSON response. You can render then the form / button inside the amp-list using amp-mustache.
This samples demonstrates how to do this: https://ampbyexample.com/advanced/favorite_button/.
Related
I'm using angular-datatables(based on jquery-datatables), reading language from Json files. It's not hard to switch datatables language through something like $scope.dtOptions.language.url = '../locales/dt/'+ lng +'.json'; but once the page refreshes, it will go back to default language. Is there any way to save language.url in cookie, and then tell datatables to read language option from cookie?
You could better use localStorage for that.
I has 2 benefits - 1) size not limited to 4kb, but starts from 5mb; 2) not being sent over the wire to server and back every request. More on comparison here Local Storage vs Cookies
The browser api is straightforward:
localStorage.setItem('datatablesLang', 'en');
localStorage.getItem('datatablesLang'); // =='en'
More details on the browser API here: https://developer.mozilla.org/en-US/docs/Web/API/Storage/LocalStorage
Besides that there's a good angular module: angular-local-storage that can do even more.
I am new to designing REST APIs. I have trying to create following APIs for online game play
GET domain/api/games // return all games
POST domain/api/games // create a new game on behalf of current user
Now my issue is that when I try to create game using POST, I want userId to be sent to the API. I am not sure how to do this. Also note that I have another get API to get details of individual game, something like
GET domain/api/games/{gameId}
so I cannot pass userId to POST like domain/api/games/{useID} as it will conflict will above API.
So how do I pass usedId to POST. Also I don't want to use query params. Any suggestions to design this would be great.
When you are making a POST to a service, the parameters you communicate are known as BODY params, they don't go on the query string.
Different technologies have different APIs for interacting with POST params, but the underlying theory is the same, and is described by the W3C HTTP standard
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
The specifics of how to use POST params vary depending on the language and technology you're using. For example, if you are using jquery, there are a couple different ways to do it, with with the $.post('url', data, callback) method or with the $.ajax(...) option.
http://api.jquery.com/jquery.post/
http://api.jquery.com/jquery.ajax/
When reading POST params on the server, you'll generally access them using some some sort of request object, that will store your parameters in memory for you to access. This is highly dependent of the language and framework you're using, but here are links to some common ones:
NodeJS/express: http://expressjs.com/4x/api.html#request
PHP: http://php.net/manual/en/reserved.variables.post.php
ASP.Net: http://msdn.microsoft.com/en-us/library/system.web.httprequest.params(v=vs.110).aspx
Java/Spring: https://spring.io/guides/gs/handling-form-submission/
It should be either part of the context (you can pass it through header) or part of the game object. I prefer the context option, the httpheader can contain some auth bearer token so that you can figure out the user on the backend through the token.
When I use LIMIT to make pages of results, how do we usually know the offset i.e. which page should be retrieved for each request?
Via cookies?
Via a query string parameter, traditionally. URLs typically include a ?page=3 to request page 3, like you'll see all over Stack Overflow: https://stackoverflow.com/questions?page=2&sort=newest
This is something you absolutely should not do through cookies. The URL should include everything necessary to navigate to the given page. Consider a user bookmarking page three of your results, or trying to link somebody else to the page they're looking at: Using cookies to store pagination data breaks these situations completely.
Usually via request parameters in action frameworks (RoR, ZF, Cake, Django) and via state of the session in component frameworks (Prado, JSF, ASP.NET). Session is usually associated with request by a cookie.
Using session to store current page is quite common in business-oriented applications, where state of the gui might be very complicated and the practically of being able to bookmark a page - limited.
I have a task to do where I need to make calls to an external xml api to fetch data for an event calendar in the sidebar of a site. The date will be changed with JavaScript and then i need to make another call to refresh the data. Can somebody give me an idea about how to cleanly set up an action or function somewhere that I can direct an Ajax action to? It's easy to set up a widget with the correct HTML etc but where does the Ajax connect to? Ideally when the content initially loads on the page it would use the same function that the post is going to use to generate the HTML on the server side.
Any tips would be appreciated. This is an xml api...no option for json or jsonp so credentials including a token and user I'm assuming will have to go somewhere in my widget, something like a proxy function?
It sounds as if you're asking about making cross-domain AJAX requests, AKA the "same origin policy."
The same origin policy prevents document or script loaded from one origin from getting or setting properties of a document from a different origin (domain). See http://www.mozilla.org/projects/security/components/same-origin.html for a more detailed description of the policy.
See Ways to circumvent the same-origin policy for a good description of the options available to circumvent this limitation.
The short answer is that unless you have control over the domain to which you're making AJAX requests, your best bet is probably to set up a simple proxy that lives in the same domain where your AJAX is running, which will forward requests to the destination. Doing a google search on "simple AJAX proxy" will get you a host of results, including pre-built proxies in a variety of languages.
I'm having trouble connecting some dots having recently learned of JSONP. Here's my understanding:
Cross-domain XmlHttpRequests for any content (including JSON) is banned, due to the same origin policy. This protects against XSRF.
You are permitted to have a script tag with a src that returns JSONP - some JSON padded inside a call to a Javascript function (say 'Foo')
You can have some implementation of 'foo' on the page that will get called when the JSONP data is returned, and you can do things with the JSON data that function is passed
Why is it OK to receive cross-domain data if it came via JSONP, but not if it came via JSON?
Is there an assumption that JSON is prone to permitting XSRF but JSONP is not? If so, is there any reason for that other than JSONP being some de-facto data format that won't ever provide data that enables XSRF? Why JSONP and not some arbitrary root tag on XML instead?
Thank you in advance for your answers, please make my brain work again after failing to figure this one out.
I understand this question to be about why the browser considers JSONP safe, not about whether it is safe (which it isn't). I will address this question step by step.
Regular ol' AJAX
To perform a regular AJAX request, the browser creates an XHR object, points it at the URL and pulls the data. The XHR object will only trust data from the same domain. This is a hard limitation. There is no getting round it in current browsers (edit - you can now use CORS).
Solution - Don't use XHR
Since XHR is subject to the same domain poilicy, we can't use XHR to do cross domain AJAX. Luckily, there are other ways to hit a remote server. We could append an image tag to the page for example. We can also append a script tag and give it a src attribute that points to the remote server. We can pull JQuery from a CDN for example and expect it to work.
How JSONP works.
When we make a JSONP request, our code dynamically appends a script tag to the page. The script tag has a source attribute which points to the remote JSONP API url, just as though you were inserting a script from a CDN.
The JSONP script returned by the server is wrapped in a function call. When the script is downloaded, the function will be executed automatically.
This is why we have to tell the JSONP the name of the callback function we want to wrap the script in. That function will be called once the script has downloaded.
Security concerns
There are some fairly big security concerns here. The script you are downloading could take control over your page and put your users at risk. JSONP is not safe for your users, it is just not blocked by the web browsers. JSONP really is a browser exploit which we are taking advantage of. Use with caution.
Used wisely, JSONP is pretty awesome though.
I don't know how the perception that JSONP is safe came up but see
JSON-P is, for that reason, seen by many as an unsafe and hacky
approach to cross-domain Ajax, and for good reason. Authors must be
diligent to only make such calls to remote web services that they
either control or implicitly trust, so as not to subject their users
to harm.
and
The most critical piece of this proposal is that browser vendors must
begin to enforce this rule for script tags that are receiving JSON-P
content, and throw errors (or at least stop processing) on any
non-conforming JSON-P content.
both quotes from http://json-p.org/ .
other links with some useful information about JSONP/security:
http://beebole.com/en/blog/general/sandbox-your-cross-domain-jsonp-to-improve-mashup-security/
Cross Domain Limitations With Ajax - JSON
JSONP Implications with true REST
all these tell 2 things - basically it is not considered "safe" but there are ideas on how to make it "safer"... though most ideas rely on standardization AND specific check logic to be built into browsers etc.