Archive for the ‘Node.ACS’ Category

Upcoming ACS changes: user session and geo query

Tuesday, June 11th, 2013

We try to be as transparent as possible about important changes that could impact your development. To that end, we are planning to roll out two ACS changes in next couple of months that may impact your application.

Application User Session Expiration

An application user session never expires today.  We are introducing the policy of expiring and removing sessions that have been inactive for 6 months.

How does it affect your application?  If your application logins a user and saves the session_id, normally stored in a cookie, every time it makes a REST call to ACS using the same session_id, the expiry clock is reset and the user gets another 6 months. As long as the ACS user is active using the same session_id within 6 months, there is no impact on your application and current logged in user. If an application user is completely inactive for 6 months or more, this user session is removed and any subsequent ACS call that requires user login such as create.json, update.json and delete.json will get a 404 error. We recommend your application can handle an invalid user session error and prompts a login screen to the user to login again.

Geo Query

ACS also currently supports MongoDB’s $nearSphere Geo Query.  Geo Query requires a field to be indexed with a geo index.  The ACS fields you can perform $nearSphere on are lnglat (pre-defined location data and only available in places and events) and coordinates (list of custom defined location data and available in all objects).  It implies that places and events have two geo indexes in the same collection and that prevents us from supporting $geoNear operation that is more powerful than $nearSphere.  We will consolidate lnglat value with coordinates values and remove geo index on lnglat field.

How does it affect your application?  For events and places, even if you never explicitly copied lnglat value to coordinates, lnglat will appear as the first element of coordinates.  Performing $nearSphere on coordinates field will return a match if it matches the lnglat value.  $nearSphere query on lnglat or coordinates will continue to work as before.


Please post your questions on Appcelerator Q&A forum with “ACS” tag or leave your comments on this blog post.

Node.ACS Tutorial 1: PixGrid photo uploader

Friday, November 30th, 2012

After launching the Node.ACS developer preview 2 last week, we are excited to share with you some real examples of how to write a kickass Node.ACS app that connects to ACS as the data backend. We’ll be sharing several more examples in the coming weeks .

Today I want to walk through a sample Node.ACS app called PixGrid which lets users signup, login, upload and view photos from a web browser. It uses ACS as the data backend to store user data and photos. You can download the source code from Github.

PixGrid is built on Node.ACS’s easy to use MVC Framework. In this app, the M(model) is ACS. We want to let ACS handle all the data storage and only focus on the application logic and view in the Node.ACS part.


This is one of the entry points of Node.ACS MVC framework projects. This file defines all the routing and filtering logic for the app.

PixGrid Routes

  • Signup
    • { “path”: “/signup”, “method”: “get”, “callback”: “application#signup” }
      This method renders the signup page
    • { “path”: “/signup”, “method”: “post”, “callback”: “user#signup” }
      This method performs the actual signup with ACS
  • Login
    • { “path”: “/login”, “method”: “POST”, “callback”: “session#login” }
      This method performs actual login action with ACS
    • { “path”: “/login”, “method”: “GET”, “callback”: “application#login” }
      This method renders the login page
  • Logout
    • { “path”: “/logout”, “method”: “get”, “callback”: “session#logout” }
      This method performs a call to ACS to logout a user
  • Photo view (query)
    •  { “path”: “/”, “method”: “GET”, “callback”: “application#index” }
      Display login page if a user is not logged in, otherwise, display photos uploaded by the user
  • Photo create
    • { “path”: “/photos/create”, “method”: “post”, “callback”: “photos#_create” }
      Upload a photo to ACS by selecting a photo file
    • { “path”: “/photos/create.json”, “method”: “post”, “callback”: “photos#_create_json” }
      Upload a photo to ACS by ajax drag and drop (only works on Chrome and Firefox)
  • Photo delete
    •  { “path”: “/photos/:id/delete”, “method”: “get”, “callback”: “photos#_destroy” }
      Delete a photo from ACS
  • Page not found
    • { “path”: “*”, “method”: “get”, “callback”: “application#page_not_found” }
      Render a page not found for everything else


PixGrid Filter

In PixGrid, most pages require a user to be logged in, so we put a checkUserSession filter to all pages

  • { “path”: “/”, “callback”: “session_filter#checkUserSession” }
    Inside the checkUserSession method, it bypasses /login, /logout and /signup


app.js is another entry point of Node.ACS MVC framework projects. It initializes the ACS and configures express, which is included in the MVC project by default. Please make sure to update the following line in app.js to fill in your own ACS oauth key and secret.


ACS user sessions

When writing apps for devices,  it is common to keep user specific information on the device and use it later because only one user can use your app at a time, however, the same code will not work well if it is running on a server because the code would be shared by multiple users.

Use photo upload as an example. If you save an uploaded file to a temp file on your Node.ACS server before sending it to ACS, you need to make sure the filename is unique for each transaction so they won’t get overwritten. For example, if user A uploads a photo to your Node.ACS server, your code stores it as photo.tmp, before the server gets a chance to send this photo to ACS, user B uploads another photo and your code will overwrite user A’s photo.tmp if you choose  to use the same tmp filename.  Check out photo.js method _create_json to see how it handles a file drag and dropped by AJAX calls.

The same goes to ACS user sessions, it is tempting to store an ACS user session on Node.ACS server for subsequent calls. But this session will get overwritten when another user logs in to ACS through the same Node.ACS server. That’s why ACS module for Node.ACS provides additional parameters (req,res) to let you pass through a user session cookie without the need to store it on the server.

    login: req.body.un,
  }, function(data) {
     // handling login callback
  }, req, res);

It is important to pass the req and res to ACS library so that it will pass along or set the cookies if needed. In the login case, it will set the ACS server returned cookie in res which will be passed back to your device. Most device handles cookies automatically so you don’t need to do anything extra on the device.

Subsequently, the photo upload call will take the cookies stored passed along by the device to ACS.

ACS.Photos.create(data, function(e) {
    if(e.success && e.success === true){
      req.session.flash = {msg:"Successfully create a photo #"[0].id, r:0};
      req.session.flash = {msg:e.message, r:0};
  }, req, res);

As long as you keep this key difference in mind, you can use almost the same code that communicates with ACS in both Titanium and Node.ACS.

Please use Node.ACS google group if you have any questions.