I've done some googling around on this topic, but there seems to be only one option: the Dropbox official API. Is there no other way i could do some sort of JSON/PHP get_file_contents etc, when you get tweets from twitter you can use the user_timeline, is there no alternative for Dropbox people have come across. I just want something i can put a username and password into the PHP script and have it get the files (or am i dreaming and will have to use the API)
Check out the Dropbox PHP SDK it uses OAuth for validation which is the safest way.
You're dreaming and will have to use the API. This is exactly what API's are for, for programming applications to talk to applications. Specifically on the subject of authentication, there would be so many security issues with just having a user/pass in your code it's not even funny. Things like OAuth and other API authentication methods exist to make this kind of thing safer and saner. Sort of like lighting a campfire in a firepit instead of the middle of a dry grassland.
There are libraries like the one fire mentions that can wrap the API and make it easier to access from your language, but you need to play by the rulebook here. I know it sounds daunting but your application will be the better for doing it right.
You could also use the hosting service KISSR which would allow you to host your entire site out of Dropbox. This would be simpler than using the API but you wouldn't be able to use PHP.
it is not that much of a odd question that has been asked. as if you are using two hosting services one of them for just hosting images the other is for interaction events, done gazillions of time, some servers use term 'content/image leeching', hard to differenciate legit useage. however thats what consumer is asking/requesting, funny answers
Related
I am new to coding and I am very confused in terms of what Firebase can do for me. I don't know how it will integrate with my web application.
My web application is going to be a ecommerce website and it will use the Algolia/Swiftype API, Stripe API and Google Maps. The website will also have 2 types of user accounts.
Just a couple of questions:
1) If I use Firebase, do I still need to use MySQL?
2) Do I need to design the Firebase database?
3) Will using Firebase speed up development time?
4) If I use Firebase, do I still need to use AWS or Rackspace?
Thanks.
No you don't need MySQL if you are using Firebase. But, there are good reasons to use one or the other, or both together. They are very different in how they work and you need to evaluate them independently for your use cases.
Not necessarily, because Firebase is "schema-less", meaning it is based entirely on the JSON data you put into it. In essence, it's a massive JSON object you put data into. (But, I'm not saying you don't need a little planning to make things work right, I'm merely saying you don't need to plan all your data types, columns, etc.)
Maybe, maybe not. It depends on how familiar you are with JSON, working with schema-less data, and working with restful services. I would argue that it all depends on what you're trying to accomplish, and how complex your system is, as to whether it will speed things up or not.
No (but maybe yes). Are you building a Node application? If you're building in Node then you can do everything through Firebase (they can host it for you). If you are delivering the first byte in something else (like PHP), then you would need a different host like AWS or Rackspace. But, you'd always have Firebase hosting your data.
Hope those answers help! Please comment under this answer if you need any clarification.
Being relatively new to web development, at least using client side technologies such as the AngularJS framework, I need to resolve a few queries before I can start my latest project.
I am writing an application using the AngularJS which reads/writes/updates data in a database. With javascript being client side I have chosen to write a PHP REST API to do the database queries, resulting in a secure username and password and a single database layer.
My question is, given my REST API, I will be using AJAX from javascript (which is client side) to invoke methods. How do I stop other sites from writing a script to invoke the REST API as well? Putting an authentication token in the javascript code isn't very secure, someone can just copy it.
Is a REST API the best approach for this problem? I am not adverse to learning new technologies or practices so please, any thoughts on better design patterns or methods of implementation are greatly appreciated. Unfortunately, due to my limited domain knowledge in this area, I have been unfruitful in my Google Searches as I'm not confident of the terms under which I should be searching.
Many thanks.
Since your Angular application is living in the browser, your REST API will need to be publicly accessible from any random visitor's browser. You thereby have a public API, out of necessity. You can't restrict it; either visitors can see the data or they can't.
Essentially this is not significantly different from a traditional webpage though. In a server-side generated page, you output your data packaged as HTML and deliver it to anyone who asks. In a REST-API/Angular app, you deliver the data packaged as JSON to anyone who asks. Either way the data is equally public, though maybe the REST API is a little easier to "abuse" than scraping the HTML would be. It may be useful to deliberate employing some user behaviour tracking and throttling, if you want to avoid someone outright sucking all of your database dry; this applies equally to JSON based REST APIs as it does to regular web pages.
If you're also exposing read/write APIs this way, you're of course wide open to abuse.
The only way to make an API non-public is to require password authentication. If the users of your site must be logged in, then you can restrict the API to anyone with a valid session. This doesn't help much in the grant scheme of things if anyone can simply register an account on your site, but it needs more deliberation and provides slightly more manageability than a completely open API.
Admin-only APIs of course must be protected in this way, requiring an account which only you have the credentials to.
First I'll outline my problem.
What I want to do is create a site. When a client connects, every second or so a number will be broadcast by him.
This is done by everybody on the site.
So every second every client receives every other clients number.
My Solution (that isn't currently making sense)
I thought of using XMPP and an OpenFire server to do this, but I can't seem to make it work with PHP.
Finally the question
Is there a better way to solve my problem than the one I outlined? Another potocol or something?
Is there something that'll play nicely with OpenFire
I already looked at these
http://code.google.com/p/xmpphp/
https://github.com/tong/hxmpp/
and Happy new Year,
XMPP, is the most common way with dealing with notifying problems, but yet you can use a less heavy approach (Technique) to deal with your problem which is Pushlets, and for sure the previous link is not the only one. Pushlets area servlet-based mechanism where data is pushed directly from server-side to (Dynamic) HTML pages within a client-browser. This allows a web page to be periodically updated by the server.
and sure it's much lighter than XMPP.
you can also use it with Java server side like in Here, which will give you some new ideas.
anyways, if you have a web application which has a lot of users you have to think twice then. and make sure that XMPP gives you a lot of controlling features over many requests. When pushlet is good enough to do your broadcasting.
Hope that will help you.
Read this http://belski.net/archives/37-Phurple-for-PHP-5.3-and-up.html
You can make it work with PHP+XMPP using the phurple extension. It works upon libpurple which is the base for Pidgin. That will make you able to work with many other protocols as well, XMPP will already enable Facebook, Google and any other XMPP based.
I have a couple of questions. I hope people can give me a good view because I am stuck at the moment.
It's a year since I started developing so please bear with me.
How can I get data from a website that I don't own to my application?
I have done some database parsing before but that's all from my own website. I see people use different library's (HPPL for example).
But what if the website requires users to login? And besides does that work on HTML only? What about if it's a PHP based site?
Should I get the external data directly on the iPhone when opening the app or should I use a middle-man approach (server between external website and app that handles the info)?
3) What is the best way to save login information so that a user doesn't have to fill in every time he opens the app?
I am a bit confused about all the stuff so maybe you can clear things up.
The question is extremely broad; so you will get pretty general answers.
Essentially, you are asking how to consume a web service. For that question, I'd recommend one of several tutorials online, like this one. There are others. That should give you a start.
You should understand the Cocoa URL loading system. The documentation is very complete. You can certainly use third-party libraries for this, such as AFNetworking; but I would recommend you understand the Apple -provided frameworks first.
But what If the website has a login ?
Depends on what sort of authentication we're talking about.
And besides does that work on HTML only ? What about if it's a php based site ?
No. Should be no different.
should I get the external data directly on the iPhone when opening the app or should I use a middle-man approach (server between external website and app that handles the info)
In general, a simple design should be favored over a more complex design so long as it meets your specifications. There's probably nothing the intermediate server can do that the iPhone cannot - but we don't really know your specs.
What is the best way to save login information so that a user don't have to fill in every time he opens the app I am a bit confused about all the stuff so maybe you can clear things up...
You will want to investigate the Keychain then. See this SO question for a bunch of tutorial references.
Let's say I have a website that has a lot of information on our products. I'd like some of our customers (including us!) to be able to look up our products for various methods, including:
1) Pulling data from AJAX calls that return data in cool, JavaScripty-ways
2) Creating iPhone applications that use that data;
3) Having other web applications use that data for their own end.
Normally, I'd just create an API and be done with it. However, this data is in fact mildly confidential - which is to say that we don't want our competitors to be able to look up all our products every morning and then automatically set their prices to undercut us. And we also want to be able to look at who might be abusing the system, so if someone's making ten million complex calls to our API a day and bogging down our server, we can cut them off.
My next logical step would be then to create a developers' key to restrict access - which would work fine for web apps, but not so much for any AJAX calls. (As I see it, they'd need to provide the key in the JavaScript, which is in plaintext and easily seen, and hence there's actually no security at all. Particularly if we'd be using our own developers' keys on our site to make these AJAX calls.)
So my question: after looking around at Oauth and OpenID for some time, I'm not sure there is a solution that would handle all three of the above. Is there some sort of canonical "best practices" for developers' keys, or can Oauth and OpenID handle AJAX calls easily in some fashion I have yet to grok, or am I missing something entirely?
I think that 2-legged OAuth is what you want to satisfy #2 and #3. For #1 I would suggest that instead of the customer making JS requests directly against your application, they could instead proxy those requests through their own web application.
A midway solution is to require an API key; and then demand that whomsoever uses it doesn't actually use it directly with the AJAX; but wrap their calls in a server-side request, e.g.:
AJAX -> customer server -> your server -> customer server -> user
Creating a simple PHP API for interested parties shouldn't be too tricky, and your own iPhone applications would obviously cut out the middle man, shipping with their own API key.
OAuth and OpenID are unlikely to have much to do with the AJAX calls directly. Most likely, you'll have some sort of authorization filter in front of your AJAX handler that checks a cookie, and maybe that cookie is set as a result of an OpenID authentication.
It seems like this is coming down to a question of "how do I prevent screen scraping." If only logged-in customers get to see the prices, that's one thing, but assuming you're like most retail sites and your barrier to customer sign-up is as low as possible, that doesn't really help.
And, hey, if your prices aren't available, you don't get to show up in search engines like Froogle or Nextag or PriceGrabber. But that's more of a business strategy decision, not a programming one.