getCookie issue with 0.1.8 using Http #305

Activity

1. vakrilov commented on Jun 23, 2016

   

   vakrilov

   on Jun 23, 2016

   Contributor

   More actions

   PR merged
2. vakrilov

   closed this as completedon Jun 23, 2016
3. vakrilov commented on Jun 24, 2016

   

   vakrilov

   on Jun 24, 2016

   Contributor

   More actions

   Btw, the quick and dirty workaround until the fix is live is to add the not implemented method(somehere in the main.ts):

   // HACK - patch dom adapter
   import {Parse5DomAdapter} from '@angular/platform-server/src/parse5_adapter';
   (<any>Parse5DomAdapter).prototype.getCookie = function (name) { return null; };
   

   👍React with 👍3Reacted by Ken Howard, Samarth Agarwal and Habib Kazemi
4. samarthagarwal commented on Jun 30, 2016

   

   samarthagarwal

   on Jun 30, 2016

   More actions

   Is it fixed yet?
5. vakrilov commented on Jun 30, 2016

   

   vakrilov

   on Jun 30, 2016

   Contributor

   More actions

   Yes - version 0.2.0 has the fix
6. SamVerschueren commented on Jun 30, 2016

   

   SamVerschueren

   on Jun 30, 2016

   Last edited by SamVerschueren

   More actions

   This is odd, are you sure this is fixed? This is what I did to confirm.

   1. Install nativescript

   $ npm install -g nativescript
   $ tns --version
   2.1.0
   

   1. Create a new fresh project

   $ tns create foobar --ng
   $ cd foobar
   

   1. Replace the code in app.component.ts with this piece

   import {Component} from "@angular/core";
   import {HTTP_PROVIDERS, Http, Headers} from "@angular/http";
   import {Observable} from "rxjs/Rx";
   
   @Component({
       selector: "my-app",
       templateUrl: "app.component.html",
       providers: [HTTP_PROVIDERS]
   })
   export class AppComponent {
   
       constructor(private _http: Http) {
   
       }
   
       public onTap() {
           this.createUser()
               .subscribe(
                   () => alert('Your account was successfully created.'),
                   () => alert('Unfortunately we were unable to create your account.')
               );
       }
   
       private createUser() {
           const headers = new Headers();
           headers.append("Content-Type", "application/json");
   
           const body = JSON.stringify({
               Username: 'foo@bar.com',
               Email: 'foo@bar.com',
               Password: 'foobar'
           });
   
           return this._http.post('https://api.everlive.com/v1/GWfRtXi1Lwt4jcqK/Users', body, {headers}).catch(this.handleErrors);
       }
   
       handleErrors(error: Response) {
           console.log(JSON.stringify(error.json()));
           return Observable.throw(error);
       }
   }

   1. Start the project

   $ tns platform add ios
   $ tns run ios --emulator
   

   1. Press the TAP button
      App will crash

   By adding the "hack", it works. The nativescript-angular version is 0.2.0.
7. vakrilov commented on Jul 1, 2016

   

   vakrilov

   on Jul 1, 2016

   Contributor

   More actions

   Confirmed - I'm still getting the crash. Reopening for investigation.
8. vakrilov

   reopened this on Jul 1, 2016
9. vakrilov commented on Jul 1, 2016

   

   vakrilov

   on Jul 1, 2016

   Last edited by vakrilov

   Contributor

   More actions

   OK, some updates:
   The fix form @NathanWalker if you pass HTTP_PROVIDERS in the nativeScriptBootstrap function. It provides a custom NSXSRFStrategy that does not use cookies - so no crash.

   However, if you add HTTP_PROVIDERS at component level (as in the @SamVerschueren's example) the built-in angular XSRFStrategy is used. It depends on cookies and causes the crash. The "load local files" goodies form #249 will also not work in this case.

   For now: You can just add HTTP_PROVIDERS in the bootstrap and everything should work fine.

   General Fix Proposal: Export NS_HTTP_PROVIDERS that can be provided at component level and provide the right XHR related dependencies.
10. vakrilov

    self-assigned this

    on Jul 1, 2016
11. NathanWalker commented on Jul 1, 2016

    

    NathanWalker

    on Jul 1, 2016

    ContributorAuthor

    More actions

    @vakrilov working up PR to handle this now. Curious your opinion:
    Should we still auto push in NS_HTTP_PROVIDERS in appProviders or should we just document that the user should instead import those and use them instead of HTTP_PROVIDERS? I could go either way.
12. NathanWalker commented on Jul 1, 2016

    

    NathanWalker

    on Jul 1, 2016

    ContributorAuthor

    More actions

    @samarthagarwal @SamVerschueren Final fix is here: #321

    Once that lands, you can use this guide: https://github.com/NativeScript/nativescript-angular/wiki/Http

    👍React with 👍1Reacted by Matthew Green
13. vakrilov commented on Jul 1, 2016

    

    vakrilov

    on Jul 1, 2016

    Contributor

    More actions

    👍
14. SamVerschueren commented on Jul 2, 2016

    

    SamVerschueren

    on Jul 2, 2016

    More actions

    I'm not familiar with the {N} core or the technical implementation whatsoever, but is it technically not possible to patch the @angular/http HTTP_PROVIDERS to just work without introducing NS_HTTP_PROVIDERS?
15. vakrilov

    closed this as completedin #321on Jul 6, 2016
16. tjvantoll commented on Jul 6, 2016

    

    tjvantoll

    on Jul 6, 2016

    More actions

    I'm not familiar with the {N} core or the technical implementation whatsoever, but is it technically not possible to patch the @angular/http HTTP_PROVIDERS to just work without introducing NS_HTTP_PROVIDERS?

    Agreed here, and I think this is going to confuse a fair number of people, especially considering the error message doesn’t point you in the right direction at all.

    If this is indeed a necessity, is there anything we can do to point people in the right direction when they use HTTP_PROVIDERS at the component level?

    cc @NathanWalker @vakrilov
17. vakrilov commented on Jul 6, 2016

    

    vakrilov

    on Jul 6, 2016

    Contributor

    More actions

    Agree - making HTTP_PROVIDERS just work would be the easiest option to use.

    However, I don't see how this can be done, because of the way HTTP_PROVIDERS are defined. The XSRFStrategy is the thing that we want to override but because it is defined inside the HTTP_PROVIDERS if you want to tell the DI to use another strategy - you should do it after including HTTP_PROVIDERS. That's how its done in the NS_HTTP_PROVIDERS.

    One more argument for the NS_HTTP_PROVIDERS is that we actually provide extended Http implementation - more on that #286.
18. burkeholland commented on Aug 31, 2016

    

    burkeholland

    on Aug 31, 2016

    More actions

    I hit this after upgrading from 0.2.0 to 0.3.0. I've always been bootstrapping with HTTP_PROVIDERS. Switching to NS_HTTP_PROVIDERS fixed the issue.