I have a Geoserver instance which serves my spatial data in WFS / WMS / WMTS formats that I then use within an Openlayers 3 application.
What I am now looking at is introducing authentication but I am struggling to work out the best way of doing it.
I want to be able to use my data within my OL3 applcation, but impost authentication if anyone wishes to access the data via desktop software such as QGIS.
Is the only approach I can take to introduce authentication on Geoserver, and then enable the layers to be used in OL3 through authenticating them? How would this be achieved?
I am thinking that PHP can be used here which would hold the username and password, that can then be passed to OL3 when a layer is requested?
This is a theoretical question and would like some advice on the best approach to take for this scenario.
Thanks
Related
I'm in the process of designing an API to service a browser web app. I want to design the API in a way where if the need arises, it can be used cross platform. For the first stage I want to implement user name and password authentication (I believe the terminology is grant_type = password). I've read up on OAuth 2.0 being a standard in practice and I have a few questions:
Is there a suggested way of binding tokens and token expiry dates to users in the database? Can this be done in one table, or is it better to keep them separate?
I want to polish up and verify username and password authentication works before exploring into having 3rd party authentication (Facebook, Google+, Twitter, etc...) Is there anything I should know ahead of time when creating the database tables and API to make sure it is extendable into these features?
I'm hearing a lot about JWT, is this considered a standard way of generating and returning tokens to the front end?
I am looking to build the api in PHP and I was going to use the implementation from https://github.com/bshaffer/oauth2-server-php but it looks like it is failing on php versions 7 and up. (I'm going to use 7.2 for this project) It may also be easier to create it myself one piece at a time.
Any direction or insight into the above would be greatly appreciated. This will be my first stab at implementing an extendable authentication framework in an app.
Im confused regarding the need of REST for a web service.Im a noob when it comes to web service,the scalability etc.
This is my requirement
-Need to fetch some data eg:names of students in a class and their photographs plus their address and stuff
-There is no authenciation/Tokens required since the data is publicly available
My question is
-Do i need to use REST for this? Will MYSQL+PHP Webservice that communicates using HTTP GET and POST do the job?
-If i go with this approach will this affect the performance of the app,when there is bulk data and will it scale?The maximum number of users that may be using the app is just 50 at a time.
-Does REST offer significant advantages,since i dont know JSON and stuff,will it payoff the learning curve?
It's better to use REST. You can just post your data as HTTP or as JSON and then process this data in your function and return result as JSON .
I recommend you to use CakePHP or Yii because it's easy to use.
In case of bulk transaction you can use MongoDb as your database.
What I would say is that REST describes a way to leverage HTTP features and use them in an optimal way. Otherwise you don't have to use all the REST mechanisms to implement a RESTful application.
I think that this link could help you to understand how to implement a Web API (i.e. a RESTful application):
Designing a Web API: https://templth.wordpress.com/2014/12/15/designing-a-web-api/
Here are my answers to your questions:
REST doesn't require an authentication to access resources. However REST integrates authentication mechanisms based on the HTTP header Authorization.
REST describes good practices in using HTTP but of course, you're free to use it as you want ;-) REST recommends to use the HTTP methods for what they actually are. To be short, GET to retrieve data, PUT / POST to update data (POST mainly to add data and PUT to update them) and DELETE to delete data. POST can also be used for what we can see as actions. REST also uses specific URIs with path variables. If I use your example, the URI for a list of students within a class would be: /classrooms/<classid>/students. REST also define a mechanism to request specific content format such as JSON based on the header Accept. In fact, you're generally familiar with most of these aspects if you implement Web applications for some years and REST provides you a way to design your application to leverage them at best.
Regarding performance, I would say no. One of the key aspect of REST is that RESTful applications are stateless. No state must be handled on the server side. This allows applications to scale more readily. I don't see any reason for bad performances regarding bulk updates. In fact, it's up to you to handle them. REST leaves the choice of the data format content sent to the server and the way to handle them efficiently on the server side. You can consider using either synchronous and asynchronous approach. For the asynchronous approach, you should return an HTTP status code 202. This approach can allow you to control the work load of updates for concurrent users. You could add the bulk updates to a queue and handle them after one per one in a separate process or thread. An example of RESTful application that uses bulk updates is ElasticSearch. See this link: http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/bulk.html.
The main advantage of REST is that it allows you to leverage HTTP mechanisms at best. Another thing that comes to mind is that there is now some tools allowing you to generate client kits to consume your application and generate documentations about the contract of your RESTful applications. See Swagger (Swagger, Swagger UI, Swagger Codegen) and RAML. These links can help you: http://swagger.io/ and http://raml.org/. Another tool, Restlet Studio (http://studio.restlet.com/#/), can help you to understand all these concepts since it comes with a sample application. Regarding the learning curve, I don't think that it's too much important since if you already implement web application, you know most of concepts.
Regarding the format you would use for content, JSON seems to be a good fit. However REST doesn't enforce any content kind. It provides a mechanism to request a specific content (Conneg, i.e. content negotiation based on the header Accept) but you don't have to use it. REST let you the way to manage this content within your application.
Hope it heps you,
Thierry
You can implement any protocol you want to do that, but using REST ensure you are following a common procedure which will make your application more maintainable.
The amount of resources used depends how do you implement the queries and responses on the server-side.
You should learn that, it will improve your knowledge as you can learn together other patterns (gateway, repository, MVC) to make your server-side professional and maintainable.
My suggestion for your application is implementing the server-side using a framework such as Laravel (I recommend), CakePHP or similar. I say that because your app seems to be just interaction with pre-defined models.
I'm developing an iPhone APP and need to implement also an Web Service.
First of all I'm not a Developer and never made something big in PHP, Objective-C, xCode.
My PHP knowledge isn't also good. But let's start with my Environment.
iPhone APP (xCode 4.2, iOS5), PHP Web Service, MySQL DB
I was researching the WEB and most People tend more to REST than SOAP. I think i see also the advantages of REST (using of simple HTTP Verbs (get, post, delete etc...), but that's not the main point here...
I think I understand the main goal of the REST Architecture and tried to make a little concept with an URI and Verb Mapping. Here just a simple example of the mapping:
/location/{location_id}/product
/location/{location_id}/product/{product_id}
Both are GET operations who should get me ether a single product or all products of a location.
How would a simple PHP REST Web Server look like with these functions?
Another part should implement a User Authentication from the iPhone. Somehow i need to store the user session, right now I don't have any idea how to make that. The goald is that if only a user is logged in, he could review the product.
Now I've researched also the Web but couldn't find an easy step-by-step Tutorial.
Do you know any good Tutorials which will help me achieve my goal? :)
A lot of people prefer using PHP Frameworks like ZEND. This seems very interesting, but it seems like a big package with a lot of modules.
Does someone know exactly which Modules are needed to get my Web Service working?
This is quite a good tutorial, it uses the codeigniter framework which makes the learning curve a bit steeper but makes it a lot more powerful in the long run.
http://net.tutsplus.com/tutorials/php/working-with-restful-services-in-codeigniter-2/
If you want to build this the custom way it's actually very easy to do if you want to return information in the JSON format especially for php5 which is generally well supported amongst hosts these days.
Essentially the steps are like this:
Pass in product id via url and retrieve using GET i.e. service.php?product_id=10
Query database and return data for product id that was passed in
Store returned data in an array
Set header content-type to application/json
json_encode the result (json_encode)
That way when you call that url in a browser you will get a nice JSON formatted array result in a key:value pair manner. And as of iOS5 json parser comes with the framework (for earlier versions SBJson is a good framework to use (SB JSON))
I have a small web app written in php / mysql that stores customer information and does various things with it.
One of my users has expressed interest in integrating my app with the custom software (also web-based) that they use for setting up customer appointments.
Basically they want a system where, when they create a new customer account using their online software, that information is automatically relayed to my application, to create the customer account on my end as well. This would save them having to enter the same information twice.
I am wondering what your suggestions are for the easiest way to approach something like this? Do I have to create a full-blown RESTful API? (I have never done anything like that before and am not really sure where to start with such a thing.) Or is there a simpler way?
Any ideas or suggestions would be much appreciated. Thanks (in advance) for your help!
In order for another application to communicate with yours, you will have to create some type of API, whether it be RESTful or not.
Personally, I recommend REST as it is fairly trivial to setup and there are LOTS of tutorials on the internet to show you how. If you use Zend Framework, it's 10x easier as they have a REST controller you can extend and quickly build an API with.
Something very simple, which has worked for me is to simply accept the information as a POST. The other application will send the information via POST, which you process in your php, and store it in mysql. if the data is sensitive, you can set up a cert and go over ssl.
Sorry in advance if my wording is wrong because I'm not quite sure how to explain what I want, so I'll just describe the end result.
I have a php based excel tool called socialcalc(it was wikicalc before). I want to allow users to connect to a database and pull live data onto the sheets(so they can run calculations on it).
I understand that for sure socialcalc will have to query mysql but I'm trying to figure out the most effective way. Is it better to allow it to query it directly? or should I have it query the database an get an xml file as a result? Or what other ways would you suggest is a efficient and secure way of allowing read access to the data?
We're building alot of the this ontop socialcalc from scratch so pretty open to all solutions but ultimately, we want this to power other services.
Update: to clarify, I am looking for suggestions on using SOAP/XML over say directly querying the database or using HTTP POST/GET,etc..which type of service layer would you suggest or what are the factors to consider when choosing?
"Simple is better than complex."
You could certainly implement a Web Service layer between your application and MySQL, but ask yourself why you would want this. You might want it because:
You plan on changing backend systems at some point in the future and don't want to have to refactor business logic in the front-end application
You want to expose your backend data to other applications and provide a common interface for doing so
You want to implement smoe sort of caching/persistence strategy in the middle tier
All of those would be valid, good reasons to use a Web Service layer between your application and your database. Certainly there are more valid, good reasons as well.
If you can't think of a reason why you should implement a Web Services layer, then don't, it's that simple. You can always decide to later when there is a good reason.
EDIT:
So you've decided to go ahead with the Web Service...congrats! I think in that case you should look at two key frameworks to save you a lot of time:
Get a good ORM framework that can generate the vast majority of your CRUD logic. Doctrine is a popular choice for PHP.
Use a Web Services framework for implementing your interfaces and business logic. I've done this in the past using the Zend Framework, as they support both XML and JSON payloads via REST. XML and SOAP are great if you need strict data validation requirements, but if you're the only one consuming your own Web Service, you don't need to impose such limiations on yourself, as you know your requirements. In that case, JSON should be sufficient.
By the way, I've discussed RESTful services via Zend in another previous question:
lightweight RESTful PHP server
I think the best approach is by using a step-to-step action.
Sep one
Let the user choose the data he want to implement in his excel sheet. How to do this is up to you.
Step two
Submit the choise of the user to a own created SQL API. This API will check the input for injections and so on and will do all the query en retrieval of data.
Step three
Send teh retrieved data to a class which will create the excel file.
Step four
Send the created excel file to the user.
The most importent part of this is the SQL api. This is a class which handles all the input from the user and communication with the database. It can use normal SQL statements but you cna use it to validate all the data.
Hopefully this is some use for you.