I have a problem with BigCommerce installation process.
According to documentation (https://developer.bigcommerce.com/api/callback) I receive GET request, do exchange for OAuth info via POST request and return HTML page to user.
App seems successfully installed, I can see it in left panel, but it don't send request to LoadCallback with signed payload. When I click to application's icon it just hides/shows HTML page that I send during intallation.
Seems like the only way to make BigCommerce do LoadCallback request is to open app after relogin.
Did I do something wrong during installation process?
No, this is intended behavior. Most apps have a sign up process that cause a frame reload of the app. You can force a reload after installation or use a form submission action via javascript. Alternatively, you can reload the control panel and reopen app or relogin and open.
Related
I'm creating a app in Ionic 2, wich consumes a web api from an existing site. To use this API i have to make athenticate in it in the following way (Similar to facebook login):
I call the api login page in a InAppBrowser component, sending the proper keys and a return URL.
the user types the login and password in the form displayed, the API will validate it and authenticate it.
The API calls the return URL passing the authorization token.
I 'hijack' this redirect to the return url in the InAppBrowser 'loadstart' event, and extract and store the authorization token.
In the following calls to the API, i send the authorization token in the header.
This is all working fine in the emulator, but it doesn't work in the browser (with ionic serve), because when i call InAppBrowser it actually calls window.open, and the events doesnt work. I can't detect the redirect action made in the opened window.
I'd like to make this work in the browser since its better to debug the application there. My first thought was to send "http://localhost:8001" as the return url, but I couldn't find a way to catch the token parameter in the ionic application.
Does anyone know how I can catch this parameter or any other way to make this login work in the browser? It is for development and debug purposes only, so strict security is not a issue (I can comment out any unsecure code in the production version).
Edit: Hayden Braxton answer didn't solve my problem, but since it was because of something exclusively to my app, and it could really help someone who wants to make plugins work, I'll keep it as the selected answer.
Besides that, I'll share the solution I found to my problem in case it could help anyone. It was simple, actually:
I pass "http://localhost:8001" as the api return_uri parameter
the api will, after checking the login and password, redirect to http://localhost:8001?token=MY_AUTH_TOKEN.
This will reload the application and call login page again.
In the login page i call this.platform.getQueryParam("token"); to get the token.
Add
"browser": "ionic-app-scripts serve --iscordovaserve --sourceMap source-map --wwwDir platforms/browser/www/ --buildDir platforms/browser/www/build",
to the script section of your package.json. Then instead of doing ionic serve, instead run
npm run browser
We use ionic2 to develop our apps where I work, and this is what we figured out after some research.
Before using this, you need to have the browser platform added. You can accomplish this with the following:
ionic add platform browser
If the browser platform is already added, delete the browser directory from your platforms directory and then run the add platform command, just to be on the safe side.
I'm curious if chrome extension overlays are delivered securely and unadulterated, and whether or not someone can "listen" to internal events.
If a user were to enter a password via a chrome extension, could I guarantee that no other browser script has recorded the password? I will hash the password with 2FA so the network request is secure, but I'm curious if anyone can get the innerHtml of an <input> within a page action.
I'm asking because I know that generally iFrames are insecure if they're hosted in an unsecure environment where they could be "replaced" with lookalike, man in the middle, phishing palettes
Thanks
Only if you injected some element into a web page it will be a part of the web page (e.g. code in an injected <script>) open to any other page script.
Internal pages and scripts of an extension like page action or toolbar popup or background page and even content script environment (variables/functions) are inaccessible from the web. With a few exceptions, you can't even directly access one from another inside your extension as those are just like different tabs/windows: messaging should be used.
The only way a web page can know what happens inside your extension is to explicitly provide it with the information from your extension. You would have to explicitly send the info via DOM messaging, for example. Or via an explicit externally_connectable mechanism.
Maybe other scripts can't record the password, however you would also need to protect the input from native components like KeyLogger, they can always get what you typed before bubbling up to browser process. So I guess a native component is also needed, it could fight with malicious keyloggers and ensure they can't get valid user input.
Update: It appears Twitter has fixed this issue. Clicking the authorize button now works! Thank you all for the responses.
I have a UIWebView that opens and directs to Twitters Oauth/Authorize webpage. The user signs in with there Twitter details and authenticates the use of our application with there Twitter account. This process worked perfect before the release of Twitter 6.37 iOS application. What happens now is when the WebView detects https://twitter.com/oauth/authorize?oauth_token instead of staying in the WebView it opens the native Twitter application and dies. If you uninstall the Twitter application everything works as usually it staying within the WebView. How can I prevent this from happening? I want to stay within my UIWebView and not automatically open deep links. I have been reading about the new URL deep link changes in iOS 9, but not sure of how to stop them from my application to other native applications. Thanks for any help!
As a workaround, in twitter authentication screen we can use the Go button on iOS typing keypad instead of using the sign in button on web view until twitter fixes.
Please refer the attached screenshot link for clarity.
Screenshot for the workaround
I ran into this issue as well and figured out it was because my authorize endpoint was set to https://twitter.com/oauth/authorize?oauth_token="+oauthToken (I believe this was in the original documentation). If you add api as the subdomain: https://api.twitter.com/oauth/authorize?oauth_token="+oauthToken, it will no longer trigger the deep linking and load the twitter app.
My answer to this via a Xamarin question:
Unless Twitter removes/updates the apps section of "https://www.twitter.com/apple-app-site-association" to allow a bypass or a secondary oauth that is not in the apple-app-site-association file I do not see how you would do it. These files are signed and iOS handles them at an OS level.
I have not played around very much with the continueUserActivity delegate and the NSUserActivity object that is passed to apps launched from UNI links, but I do not see a way for the launched app (i.e. Twitter) to return control to the original app, and at that point the oauth call-chain would be broken anyway....
Unique. Unlike custom URL schemes, universal links can’t be claimed by other apps, because they use standard HTTP or HTTPS links to your website.
Secure. When users install your app, iOS checks a file that you’ve uploaded to your web server to make sure that your website allows your app to open URLs on its behalf. Only you can create and upload this file, so the association of your website with your app is secure.
Via: https://developer.apple.com/library/prerelease/ios/documentation/General/Conceptual/AppSearch/UniversalLinks.html
I would report as an issue (bug?) to Twitter's Dev forum: https://twittercommunity.com
I'm trying to develop a rally app using the app builder. When I load App-debug.html in my browser, I am prompted to enter my user credentials in the form provided. I enter them, but the form re-appears over and over again.
I did notice that the login attempts to authenticate via https://rally1.rallydev.com:443. If I go to this in another window and enter my account details I am able to get in. However, when I do log in, there is a corporate redirect that takes place (for SSO) and I ultimately end up on us1.rallydev.com.
How would I get my app to authenticate through us1.rallydev.com. Changing urls in App.js and config.json only causes errors when trying to load javascript for APIs.
The app should always just piggyback on your existing session. Changing the serverin config.json and re-running rab build should cause all traffic to go to that server- if that's not happening then that's a bug.
You won't be able to authenticate from scratch using SSO from an app, but it should have no problem re-using an existing session.
Another option is to use an API Key to develop: https://help.rallydev.com/apps/2.0/doc/#!/guide/embedding_apps
When writing a Worklight app it is verboten to change the URL of the DOM in which the application is running. This makes sense as a hypertext move to another URL will obliterate the state of the app.
On occasion however, in my app I receive a URL for a news article and the user wishes to read it. Displaying the new content in an iFrame would start to address the requirement, but then I need navigation controls, etc. and it starts to feel like I am reinventing a wheel.
Does Worklight, or one of the mobile JS frameworks provide a "browser in browser" experience that I need here?
Worklight utilizes Cordova. Cordova makes it possible to display just what you wanted, a "browser in a browser" - InAppBrowser.
The InAppBrowser is a web browser view that displays when calling
window.open(), or when opening a link formed as <a target="_blank">.
Try that.
No setup is required as the InAppBrowser plug-in is already part of the Worklight project (this may differ depending on your Worklight version; If you are using 6.x you're OK).
All you need to do is to call up the URL. For example, in yourProject\apps\yourApp\common\main.js:
function wlCommonInit() {
window.open('http://apache.org', '_blank', 'location=yes');
}
Once the app initializes it will open the InAppBrowser:
And once tapping the Done button, you're back in the app.
You can of course not specify the location attribute so the navigation bar won't display. In that case, in order to go back to the app the user will need to tap the Back button: