Open adam-s opened 9 years ago
You can look at "yo hedley" it scaffolds a headless drupal that includes authentication and organic groups. On Jun 19, 2015 11:17 PM, "adam-s" notifications@github.com wrote:
I'm not sure the best place to ask this question. I've been looking at this module and the opensource project Negawatt https://github.com/Gizra/negawatt-server for information how to use them.
How do serve a headless Drupal app? Do I run a node.js server or do I set ng-app within a Drupal template?
I'm asking because I'm thinking about the best way to authenticate a user and create a persistent session. There is cookie authentication and token authentication. Negawatt uses token authentication but I've been reading that storing a token in localstorage has security risks. How does negawatt's use of RESTful module's tokens overcome these risks? If I embed the ng-app inside of not headless drupal how does cookie authentication with token authentication work? How about creating new accounts, updating accounts, deleting accounts, and responding to forgotten passwords using headless Drupal?
— Reply to this email directly or view it on GitHub https://github.com/RESTful-Drupal/restful/issues/538.
btw @adam-s how did you find Negawatt? :)
I found Negawatt by looking at repositories of people involved with RESTful looking for better examples of how to use it. Very cool stuff. Installing hedley was easy enough.
From chat:
me: about https://github.com/RESTful-Drupal/restful/issues/538#issuecomment-113793120 i.e. keeping the token in local storage you have any insight about security - or how to improve (i.e. somehow hash the token per machine)? Mateu: I was thinking about that. But all of the convoluted solutions have a performance toll that you don't want to pay me: + i'm not sure about the security risk as you can't login to Drupal with that token Mateu: but you can access private data with it me: indeed Mateu: if a malicious app gained access to execute local scripts and the token is there in plain text. But your idea of hasing the token with drupal salt in the client is good You get the plain token from drupal access an endpoint that requires user/pass access in Drupal that returns the drupal salt encript the token on saving on the browser and then send the encrypted token whenever you want to be authenticated The server will get the encrypted token + the desired user email/uid and try to encript the recorder token for that user, with the drupal salt me: the encrypted token should change from machine to machine Mateu: so in the end you need to: send encrypted token + uid or plain token Hmmm if it should change from machine to machine you need access to a machine ID me: otherwise encrypted token == token Mateu: from JS for encryption And an attacker would have access to that too otherwise encrypted token == token you would also need the email / uid which should not be in the browser me: or maybe we could use the $_SESSION id in the salt. And then the token will expire with the $_SESSION Mateu: that's worth exploring me: yeah, I've done some reading, but haven't found a good solution yet..
Have you looked at ng-token-auth for AngularJS and its related Ruby Gem devise_token_auth?
I'm not sure the best place to ask this question. I've been looking at this module and the opensource project Negawatt for information how to use them.
How do serve a headless Drupal app? Do I run a node.js server or do I set ng-app within a Drupal template?
I'm asking because I'm thinking about the best way to authenticate a user and create a persistent session. There is cookie authentication and token authentication. Negawatt uses token authentication but I've been reading that storing a token in localstorage has security risks. How does negawatt's use of RESTful module's tokens overcome these risks? If I embed the ng-app inside of not headless drupal how does cookie authentication with token authentication work? How about creating new accounts, updating accounts, deleting accounts, and responding to forgotten passwords using headless Drupal?