I am designing an application which uses an API key provided to me by a company.
In order for me to make my application public, I need to hide the API key in my released product, because currently it is sitting in JS code and visible to all users.
My app basically provides real-time statistics, and is completely functional, but only at the JS level.
From my understanding, in order to hide my key, I need to do the following:
Client uses web app --> AJAX call to MY server --> Gets my API key --> AJAX call to company's server --> Return only the object from the company's server to the client web-page.
I have written PHP, JS, SQL, and HTML before so I'm FAMILIAR with the languages, but this chain of events seems a bit over my head.
Usually I buy books to understand this type of thing but it seems like a pretty specific example that some of you guys would be able to help me with.
Can anyone explain how this might be done, using layman's terms? I'm not completely stupid but my biggest roadblock here are the following two concepts:
How can you AJAX call to a PHP page, and tell it to make another AJAX call to an external server?
How do you execute that second AJAX call? Is it just another (hidden) js file?
The stats are provided in real time, so you type a name in, and it generates a graph on the page within less than a second. I want to keep it like this and not have the user refresh the page.
Thanks so much. Let me know if you need any more information from me.
Related
In Facebook, or StackOverflow, we notice that even when we DO NOT refresh the webpage, occasionally we get notified on the top navigation bar that certain events have happened.
Usually we term these as push notifications.
I have a working CakePHP 3 web app and the client requests for this kind of feature.
How do I implement this within CakePHP 3 framework?
There is this new thing called View Cells. Does that help?
I am opened to javascript solutions as well.
EDIT:
I can implement a json API if need be. I am proficient enough to do that. I am just not familiar with what to do in the front end.
You will have to use JavaScript in one way or another, view cells are unrelated in the sense that they are purely server side technology that assists in view rendering.
The StackExchange sites are using WebSockets for these notifications, Facebook used to use long polling AJAX requests if I remember correctly (not sure if they still do)...
There are various ways to implment something like that, the term you should be looking for is Comet
https://stackoverflow.com/questions/tagged/comet
http://en.wikipedia.org/wiki/Comet_%28programming%29
As I can't orientate freely in the topic of building dynamic sites, it is quite hard to me to google this. So I'll try to explain the problem to you.
I'm developing a simple social network. I've built a basic PHP API represented by the files like "get_profile.php", "add_post.php", etc. with the POST method that is used to pass some data. Then I try to get the data using JS AJAX (php functions return it by JSON), which means I get all the data that I need to show on a page after the page is loaded. That causes decreasing of a page loading speed and I feel like this structure is really wrong.
I hope you'll explain me how to build a proper structure or at least give me some links to read. Thanks.
Populate the HTML with the (minimum) required data on the server side and load all other necessary data on the client side using AJAX (as you already do).
In any case, I would profile your application to find the most important bottle necks. Do you parallelize AJAX requests?
Facebook, for example, doesn't populate its HTML with the actual data on the server side, but provides the rough structure, which is later filled using AJAX requests.
If I understood your architecture right, it sounds ok.
Advices
Making your architecture similar to this allows you to deliver templates for the page structure that you then populate with data from your ajax request. This makes your server faster also since it doesn't have to render the HTML also.
Be careful with the amount of requests you make though, if each client makes a lot of them you will have a problem.
Try and break your application into different major pieces and treat each one in turn. This will allow you to separate them into modules later on. This practice is also referred as micro-services architecture.
After you broke them down try and figure user interaction and patterns. This will help you design your database and model in a way in which you can easily optimise for most frequest use-cases.
The way of the pros.
You should study how facebook is doing things. They are quite open about it.
For example, the BigPipe method is the fastest I have seen for loading a page.
Also, I think you should read a bit about RESTful applications and SOA type architectures.
I have a website A with a database and a search engine of some object, user can create account on my website then add comment for these objects.
I need to create an api with something like a plugin, it will result on having the seach engine on another website B.
I have planned to do like fb or twitter plugins : the dev who want to use my api will just need to add a line of js, and a line of html on website B, then it will load the plugin. But I'm wondering how to organize it.
Here it what I've guessed : I create a page on my website A, put the search engin on it. I create a js that will load this page whithin an iframe, on the dev's page (website B), under the div he added to have my plugin. Then I implement OAuth 2 (with a provider and so, so people can do post requests to alter my db), and people who is one the website B will have the ability to post comment on the objects of the search engine on website B.
Actually it seems to be the same as fb comment plugin process, but it seem too complicated to do all that stuff. Is it the right way? Can anyone detail the problems that I should face during implementation?
You need to develop a decent API which can return search result in JSON (and XML if you want to please everyone). That already would offer other developer the ability to use your site functionalities, that's mostly back end work tho. So they can develop their own widget.
To develop your own widget as a search widget you don't need that much, you just need either a set target (maybe a required element) or/and an initialization method (more flexibility for the dev) to which you pass a target.
Bind the search button, grab terms search, call your API and when you get your result display them or/and execute a custom callback pass the result as an argument, flexibility)
If you do your javascript well you can create a little API there too which facilitate the usage of your API via javascript. And then even easily port it to a jQuery plugin or something similar.
When serving JSON always remember to set your headers for your API to allow for crossdomain or go for jsonp instead.
Your question implies an architectural direction, but the requirements are too broad for such a choice. I would narrow down your requirements first. OAuth 2.0 could potentially help satisfy your needs, but ask yourself at least the following:
What user data needs to be protected?
What 3rd-party data access is needed? What functionality?
If you go with OAuth 2.0, are you prepared to follow a spec which is still changing? Are you willing to be the authentication provider?
What server-side languages/platforms are acceptable?
What other security considerations are important to you? (Such as social sharing, level of 3rd-party app trust...)
How much are you willing to rely on 3rd-party tools? Or write your own?
I agree that modeling your design off FB or Twitter or Google is not a bad idea, as they have done this sort of thing.
You might have a look at the new book Getting Started with OAuth 2.0.
Here are two simple ways of making custom search available to users.
The simplest option is to do what Google does - the search on your site would follow a simple, well defined API - so that
www.mysite.com/search?q=keyword1+keyword2
returns a list of results in HTML.
Then you'd tell your users to include a snippet of HTML:
<form action="http://www.mysite.com/search" method="get">
<input name="q" type="text" value="Search">
</form>
That would do, though at this juncture you may want to improve things with better search options, a javascript wrapper for the search form, a JSON or XML format for the data returned, security, a better worked out API that takes all these into account.
Another way is to use javascript and provide the data with a callback facility, so the URL:
www.mysite.com/js-search?q=keyword1+keyword2&callback=someHandle
will return a javascript file containing JSON data and a call to "someHandle" when it is loaded. The developer using your API have to write their own way of making the request and the handler. Bear in mind that because of XSS, the queries would probably come from your partners' servers. The simplest is probably to make your own search offer simple and well-documented so others can exploit it.
OAuth 2 could be helpful just if you would allow the website B to make POST request to the website A in background.
Instead if you want allow the users that visit the website B to post a comment then the iframe with a form that point to the website A is enough.
The easier bet, yet not necessarily the wisest, is to create some JS which calls on your website using JSONP.
iFrames are not W3C standard, try avoiding them if possible. Code a Javascript with some events that will do some JSONP calls into your own server and return the results in Javascript accordingly, so it would be able to interact with the page.
I've developed a system that polls a server and injects the response JavaScript into the clients web page. I want to obfuscate the JavaScript the server serves, but I also want to know if there is a tool that dynamically obfuscates it according to a token or key. Meaning every new session gets unique scripts that will only work with that client during that session.
If this doesn't already exist, could someone maybe provide me with a link on how to write my own JavaScript obfuscation tool.
Chris, I encourage you to look at this a different way.
First of all, your problem seems to be that you want to display something on your web page, but you want to disguise the methodology that it got there. The absolute best way to do this is to execute all of your code on the server.
This frees you up so that you don't have to obfuscate anything. Any Javascript that you execute would just be working on raw data anyway, and wouldn't be anything specialized that a hacker could do anything with.
A hacker could not see your business processes if all of the work was done on the server.
So, you can make an Ajax call out to the server, which executes the code, and returns HTML or JSON data that your app can then use to place on the webpage. The hacker has nothing to go on, and you don't have to build obfuscation into anything.
Heres a page that encrypt javascript acording to a key
http://scriptasylum.com/tutorials/encode-decode.html
Something you can do, to hide your javascript, is to send it this way:
<?php
header("Refresh: 0;javascript:document.writeln('');");
?>
your js code here
I have not tried it,but I think It will create a empty page wen viewed by a browser.
Web-Applications these days make extensive use of Javascript, for example various Google Products like Gmail and Calendar.
I'm struggling to how NOT having duplicated logic server and client side.
When requesting a page or state of the application, i would prefer to send the complete UI, meaning: not just some javascript, which in turn makes a dozen ajax requests and builds the user interface.
But here lies the problem, the logic deciding what to show or not has to be written once in the server-side and once in the client-side language.
Then i was wondering if it was somehow possible to process your javascript logic server-side and send the whole to the client, who in turn can continue using the application with all the advantages of a responsive ui, but without disadvantage of the initial loading/building of the user interface due dependency of background ajax requests.
I hope the explanation of my problem is a bit clear, because i'm not the most fluent English writer. If you understand what i mean and if you can describe the problem a little better, please do... thanks!
So my question is:
Is something like this possible and or realistic?
What is your opinion on how to tackle this problem?
;-)
When we started our web app, we had the same kind of questions.
It may help you to know how we ended:
The backend (business logic, security) is totally separated from the frontend (gui)
frontend and backend communicate through JSON services exclusively
the JSON is rendered client-side with the PURE templating library
and the backend is Erlang (anything streaming JSON would be ok too, but we liked its power)
And for your question, you have to consider the browser as totally unsafe.
All the security logic must come from the backend.
Hiding or showing some parts of the screen client side is ok, but for sure the backend decides which data is sent to the browser.
Seems you describe Jaxer.You can write everything in JS. Also, there is GWT that allows to write whole thing on Java
Then i was wondering if it was somehow
possible to process your javascript
logic server-side and send the whole
to the client, who in turn can
continue using the application with
all the advantages of a responsive ui,
but without disadvantage of the
initial loading/building of the user
interface due dependency of background
ajax requests.
Maybe the apps you're looking at just use Ajax poorly.
The only content you can pre-process on the server is the content you already know the user wants. For example, in an email app, you could send them a complete view of their inbox, pre-processed on the server and fetched with a single request, as soon as they log in. But you might use AJAX to fetch a particular message once they click on it. Sending them all the messages up front would be too slow.
Used correctly, AJAX should make your pages faster, because it can request tiny updates or changes of content without reloading the whole page.
But here lies the problem, the logic
deciding what to show or not has to be
written once in the server-side and
once in the client-side language.
Not necessarily. For example, in PHP, you might write a function like displayWidgetInfo(). You could use that function to send the initial widget information at page load. If the user clicks the widget to change something, send an AJAX request to a PHP script that also uses displayWidgetInfo() to send back new results. Almost all your logic stays in that single function.
Your instincts are correct: it's bad to duplicate code, and it's bad to make too many requests for one page. But I think you can fix those problems with some refactoring.
I understand what you're saying.
But I don't think you should be having much 'logic' about what to build, on the client side. If you did want to go with a model like you're proposing (not my cup of tea, but why not), I don't see why you'd end up with much duplicated.
Where you would normally show a table or div, you would just output JavaScript, that would build the relevant components on the client side.
I would consider it just as another 'View' into your data/business logic model.
Have you go a small example of a problem you're coming up against?
I understand your question in this way:
Suppose we have an html form on web-page. There is a field for name and surname. We have to check it for validity both on client-side (with JS) and Sever-side (on php script while processing form inputs). So here is the duplication - regex check on both sides. So what is the way to prevent it and combing these logics?