1. #1
    Sencha User
    Join Date
    May 2011
    Posts
    28
    Vote Rating
    0
    chearner is on a distinguished road

      0  

    Default Answered: Session vars and security managment

    Answered: Session vars and security managment


    I've looked around but there doesn't seem to be much mention of security or sessions in Sencha Touch. The security part of Touch eludes me.

    Can anyone point me to a tutorials or discussions on Touch application security?

    Specifically I have setup my app to use ASP.net MVC on the backend, I can login and sessionStorage.setItem("loggedIn", true) but what is the best strategy for accessing my session vars on the server with my pages in Touch?

    I'm also trying to figure out what to do next to lock down parts of my app from not logged in users, etc.

    How could I display a username in a header or page within my app, like a webpage would show your username in the top corner, with a link to logout?

    On other security notes, can sencha touch apps be easily hacked? how can we protect form fields from script injection? Are the PhoneGap considerations when using session vars, etc?

  2. Application security on the client is only a stop-gap to the larger problem.

    If you're worried about script/SQL injection into form fields, you have to lock down the inputs on the server. Period. Anyone can hack the client application using Firebug, dev tools, etc... it's a moot point, and it's been debated on these forums more times than I can count (usually related to ExtJS).

    Moving on... you have a handful of options to get your session vars into the client.

    One approach is to inject them via ASP.NET into some sort of global object when the page is served. Another might be to make an AJAX request, and return the vars in the response (encoded as JSON).

    As for "locking" parts of your app, you can easily add logic to your application (maybe in the constructors of your classes) that chooses to allow parts to be rendered dependent on users' access levels. The caveat here is that you can't ever guarantee the client is secure. You're basically trying to fake security.

  3. #2
    Sencha - Services Team arthurakay's Avatar
    Join Date
    Sep 2008
    Location
    Antioch, IL
    Posts
    1,365
    Answers
    60
    Vote Rating
    33
    arthurakay is a jewel in the rough arthurakay is a jewel in the rough arthurakay is a jewel in the rough

      0  

    Default


    Application security on the client is only a stop-gap to the larger problem.

    If you're worried about script/SQL injection into form fields, you have to lock down the inputs on the server. Period. Anyone can hack the client application using Firebug, dev tools, etc... it's a moot point, and it's been debated on these forums more times than I can count (usually related to ExtJS).

    Moving on... you have a handful of options to get your session vars into the client.

    One approach is to inject them via ASP.NET into some sort of global object when the page is served. Another might be to make an AJAX request, and return the vars in the response (encoded as JSON).

    As for "locking" parts of your app, you can easily add logic to your application (maybe in the constructors of your classes) that chooses to allow parts to be rendered dependent on users' access levels. The caveat here is that you can't ever guarantee the client is secure. You're basically trying to fake security.
    Arthur Kay
    Developer Relations Manager, Sencha Inc.

    Twitter | Sencha Chicago User Group

Thread Participants: 1

Tags for this Thread