Can this plugin override all HTTP calls? about http HOT 26 CLOSED

@mraible FYI: I’ve got the Okta Sign-In-Widget working on iOS as well. The Okta Auth JS SDK supports adding your own http request implementation. You can pass the custom implementation via the authParams configuration of the Sign-In-Widget. Using the capacitor http plugin, you can then override the requests as follows which works great for my use case:

widget = new OktaSignInWidget({
  ...
  authParams: {
    httpRequestClient: async function(method, url, args) {
      const { Http } = Plugins;
      const { headers, data } = args;
      const ret = await Http.request({
        method,
        url,
        headers,
        data
      });
      const responseMsg = {
        responseText: JSON.stringify(ret.data),
        status: ret.status
      };
      return Promise.resolve(responseMsg);
    }
  }
});

from http.

@TomBeckett I have made progress in convincing Okta that they should support capacitor://localhost as a trusted origin. Unfortunately, our engineering team hasn't committed to a date yet. I'm hoping before the end of the year.

from http.

We use capacitor:// in @capacitor/ios because of a previous security issue we had when using http:// in older versions of capacitor. We use that scheme to communicate between the native layer and the webview. Unfortunately Apple prevents us from overriding/extending the http:// scheme, so we can't intercept HTTP calls and that could lead to a mismatch between the native and web layers.

Here is the relevant part of the Apple Docs

It is a programmer error to register a handler for a scheme WebKit already handles, such as https, and this method raises an invalidArgumentException if you try to do so.

Hence why we use capacitor://. I'll be sure to update when I get a chance to dive into this more, but I don't have an answer yet

from http.

from http.

@mraible Yes, it's working well.

from http.

@FelixSchwarzmeier
We use Outsystems for the Frontend development that is powered by Cordova.
We were able to pass invoke apis using Cordova HTTP as you detailed about overriding the httpRequestClient.

We now have the following issue:, want to check if that was the case in your implementation too?
Unrecognized Content-Security-Policy directive 'report-to'.
Unable to post message to https://xyz.outsystemscloud.com. Recipient has origin outsystems://xyz.outsystemscloud.com.

from http.

@mraible Did you happen to get any further with this?

from http.

@mraible has Okta added capacitor://localhost as a trusted origin yet? Either way, I'll take a look at the underlying issue with the capacitor:// scheme

from http.

@thomasvidas We did last week. However, we had to roll it back because the implementation caused all kinds of issues with existing data.

from http.

@mraible is Okta currently trying to find a new solution/implementation to be able to add capacitor://localhost as a trusted origin or is this on hold at the moment?

from http.

@mraible can you already give an ETA for the new solution?

from http.

from http.

@mraible Okay, thanks for the quick reply!
Have you found another way to get the Okta Sign-In Widget working in a Capacitor application on iOS?

from http.

from http.

@thomasvidas Have you alrady had the chance to look at the underlying issue with the capacitor:// scheme?

from http.

I see, thanks for the detailed explanation!

from http.

@mraible I tried your recommended approach using your OktaDev Schematics project. I can transfer the access- and id-token to my application’s WebView. However, I am currently not able to get any session cookie information that I need to SSO into my applications. Using the Okta Sign-In Widget, I was able to set the Okta session cookie, do you know how I could achieve the same result when redirecting to Okta to login?

from http.

@FelixSchwarzmeier Why do you need a session cookie? You might have better luck asking how to accomplish your use case on the Okta developer forums.

from http.

@mraible I need a session cookie to Single-Sign-On into my applications. Okay thanks, will create a new topic there.

from http.

It's been a couple of weeks. @FelixSchwarzmeier Is this working well for you?

from http.

@FelixSchwarzmeier

Does this fix require the Capacitor-http plugin?

from http.

@SmartPlugins Yes, it requires the Capacitor http plugin to avoid any CORS issues.

from http.

@SmartPlugins Sorry, I've never encountered this issue.

from http.

I have the same issue as @SmartPlugins when trying @FelixSchwarzmeier's workaround.

Unrecognized Content-Security-Policy directive 'report-to'.
Unable to post message to http://localhost. Recipient has origin capacitor://localhost.

--- UPDATE ---
Finally figured it out, make sure on ios the redirectUri is capacitor://localhost/something and on android http://localhost/something. You also don't need the http plugin anymore, seems like okta is now allowing capacitor:// in the trusted origins/cors.

Very unrelated to the orignal issue, just figured it might help @SmartPlugins.

from http.

Closing this since it seems that Okta is allowing capacitor:// as a trusted origin as well as the open RFC on the Capacitor repo

from http.

@mraible FYI: I’ve got the Okta Sign-In-Widget working on iOS as well. The Okta Auth JS SDK supports adding your own http request implementation. You can pass the custom implementation via the authParams configuration of the Sign-In-Widget. Using the capacitor http plugin, you can then override the requests as follows which works great for my use case:

widget = new OktaSignInWidget({
  ...
  authParams: {
    httpRequestClient: async function(method, url, args) {
      const { Http } = Plugins;
      const { headers, data } = args;
      const ret = await Http.request({
        method,
        url,
        headers,
        data
      });
      const responseMsg = {
        responseText: JSON.stringify(ret.data),
        status: ret.status
      };
      return Promise.resolve(responseMsg);
    }
  }
});

I have created a repo that implements this solution:

https://github.com/phofferkamp/Ionic-Okta-Widget-Starter

from http.