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 - Tools Team arthurakay's Avatar
    Join Date
    Sep 2008
    Location
    Antioch, IL
    Posts
    1,414
    Vote Rating
    48
    Answers
    64
    arthurakay is just really nice arthurakay is just really nice arthurakay is just really nice arthurakay is just really nice

      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.

Thread Participants: 1

Tags for this Thread