{"version":3,"sources":["webpack:///./src/pages/writings/drupal-web-service/drupals-services-module.tsx"],"names":["DrupalsServiceModule","sidebar","writingsSidebar","title","href","to"],"mappings":"4FAAA,2DAkKeA,UA7JwB,kBACrC,YAAC,IAAD,CAAQC,QAASC,IAAiBC,MAAM,4BACtC,+CAC0B,IACxB,iBAAGC,KAAK,sCAAR,YAFF,igBAWA,odASA,mTAIyE,IACvE,iBAAGA,KAAK,qCAAR,kBALF,mJASA,0CACA,8iBAUA,2mBAWA,+CACA,u2BAeA,4lBASW,6BATX,wVAeA,4YAQA,oCACA,29BAc0B,iCAd1B,wQAoBA,okBAUA,6dASA,uBACE,6HAKF,sOAKA,sBACE,sBACE,YAAC,OAAD,CAAMC,GAAG,8CAAT,mBAIF,sBACE,YAAC,OAAD,CAAMA,GAAG,uEAAT","file":"component---src-pages-writings-drupal-web-service-drupals-services-module-tsx-3ceb92fb35a872953040.js","sourcesContent":["import { Link } from \"gatsby\";\nimport * as React from \"react\";\n\nimport Layout, { writingsSidebar } from \"../../../layouts\";\n\nconst DrupalsServiceModule: React.FC = () => (\n \n

\n Luckily, Drupal has the{\" \"}\n Services module, which\n does most of the work for us. This module allows communications through\n XMLRPC, a simple protocol for remote procedures over XML; JSON, the\n Javascript object notation; REST, a stateless, modern interface; SOAP, a\n heavier protocol for remote procedures over XML; AMF, the system required\n to speak with Flash programs; and many other acronyms. The Services module\n is relatively easy to extend, so other communications protocols may be\n added in the future without affecting the core functionality.\n

\n

\n The Services module uses API keys, which allow you as the site admin to\n give out and revoke access through these interfaces whenever you see fit.\n In general, this is a very powerful tool employed by almost all service\n providers as it allows you to track who is accessing what and limit/grant\n access as needed. At the moment, the Services module provides rudimentary\n systems for these API keys, allowing you to create and revoke them as\n needed.\n

\n

\n In general, you’ll find the documentation for this module a bit\n lacking. Most of it centers on AMF because (as far as I am aware) Services\n + AMF is the only way to create a Flash-based Drupal site. Unfortunately,\n much of the documentation is out of date or oddly specific. There is a{\" \"}\n Services Group which can\n probably answer your questions much better than the existing\n documentation, though you should, of course, fix said documentation ;).\n

\n

Provided Modules

\n

\n The Services project is actually a collection of several modules; there\n are also additional modules for providing more functionality. All of these\n modules basically fall into one of two categories. The first,\n “Servers,” represent entry points (i.e. protocols) to your\n site. As mentioned before, these include JSON, REST, and XMLRPC (which\n comes included with the Services project). All examples in this\n presentation will utilize XMLRPC because it is in the base project, it has\n lots of library support, and it’s very simple to model.\n

\n

\n The other category, “Services,” represent the functionality\n which you’d like to make accessible to others. For example, the\n Services project comes with the Node service, which allows you to get,\n save, and delete nodes from afar. We’ll discuss this service as well\n as the System service, which allows for connecting to the server,\n getting/setting variables and checking which services are available, as\n well as the User service, which allows us to log in as a particular user\n and manage users. The project also provides services for accessing files,\n menus, search results, taxonomies, and views.\n

\n

Permissions and Users

\n

\n The developers of the Services module chose a very elegant solution for\n dealing with permissions/users. Instead of implementing their own\n services-specific framework, they chose to reuse Drupal’s core user\n functionality. This means that every service request is performed as a\n specific user (including the anonymous user), and the ability to access\n these nodes, etc. is limited based on that user’s permissions. This\n has several implications on how you’ll need to set up user\n permissions, but the first of which is that you will need to grant the\n anonymous user permission to access services. This is because no user\n begins their existence logged in; they always start as an anonymous user\n and then sign in. Following the same scheme, your service receiver will\n start its existence as the anonymous user and then (usually) log in as\n another user.\n

\n

\n As I see it, there are two basic models for structuring how your Drupal\n users relate to services. In the first model, you can extend existing\n logins by adding additional service permissions to them. This mechanism is\n particularly good if you need a paper trail, for example if you will be\n allowing users to update content through services. Unfortunately, this\n mechanism also requires that you personally keep track of which users have\n what access, which I find is more pain than it is worth. The alternative\n is to use a more Unix-style “daemon” user for each service. In\n this way all services that need to search (for example) act as\n the same user. This is useful for anonymous, read-only services where it\n is more important to know how often particular services are used rather\n than which user is using them. The analogue would be apache, which acts as\n the www-data user regardless of the ip address accessing your server.\n

\n

\n Before we get too much further, I wanted to note that on several\n installations of the Services module, I’ve needed to rebuild user\n permissions. If you see that you should be able to access a service but\n cannot, try rebuilding these permissions in Admin > Content Management\n >Post Settings. I’m not too sure what the problem is, nor if it\n has been fixed in later versions.\n

\n

The Web UI

\n

\n The Services module offers a highly functional web ui which allows you to\n not only handle administrative tasks, but also test your services. You may\n find this UI (once Services is installed) at Admin > Site Building >\n Services. You’ll first notice the API Key management tool which\n allows you to manage your API keys. Services are not accessible to anyone;\n you must generate a key for users to specify when accessing your services.\n At the moment, this interface forces API keys to be generated by a system\n admin, though I don’t see any reason why you couldn’t develop\n a module which auto-generates these per user. This is also the location to\n revoke access for a specific key. As soon as you do this, that user will\n no longer have access to any of the services you granted to that key. Note\n that when generating keys, you give both an application title and allowed\n domain. The title is a way to signify the purpose of this key/who will be\n using it. I believe the purpose of the domain was to restrict key\n access to only certain IPs/domains, but this doesn’t appear to be\n implemented at this time. In fact, as we will see in a moment, the service\n receiver simply provides the “domain” string as a parameter\n when accessing services.\n

\n

\n You will also see your API documentation, which describes exactly what\n services, what parameters they require, and what type of data they should\n give back. This information is what you will want to publish elsewhere on\n your site so that users will know how to access your services; they will\n also be able to retrieve this information from the “system”\n service, which we will discuss in a moment. These pages also provide an\n interface for testing your methods to confirm that they return the right\n data without forcing you to connect via XMLRPC, JSON, etc.\n

\n

\n It’s important to note that viewing/testing these services requires\n a url of the form /admin/build/services/browse/servicename.method . That\n is, the urls include a period, which may confuse certain web server\n configurations which treat any url with a period as a file path (rather\n than rewriting into “clean URLs”). If you can’t view the\n documentation, these web server rules are probably to blame. For example,\n in my lighttpd configuration, I’ve added\n

\n 
\n      \n        “^/admin/build/services/browse/(.*)\\.(.*)$” =>\n        “/index.php?q=admin/build/services/browse/$1.$2”\n      \n
\n

\n to the top of the list of url rewrites. Whenever one of the Services api\n pages is hit, this rule will rewrite it use the q= parameter, which would\n not normally occur since there is a period within the url.\n

\n \n \n);\nexport default DrupalsServiceModule;\n"],"sourceRoot":""}