We're having a problem with physical iOS devices (works fine on Chrome virtual device) where a final Seaside redirect is not happening after an Azure SSO redirect.
I'd like to understand what triggers the Seaside redirect: I can see it in normal rendering, but I've never had to dig into it like this before.
When I log from a non-iOS device I see...
1 - WAApplication>>handleFiltered: application URL
self requestContext redirectTo: 'https://login.microsoftonline.com/...'
redirects back to our app URL with an access token
2 -WAApplication>>handleFiltered: application URL with MS access token & no _s & _k values
validate token with Azure
save user info in new WASession
finish render
3 - WAApplication>>handleFiltered: application URL with _s & _k plus callback values like: &2=2160&1=3840&3=false
WAResponse>>location: application URL with _s & new _k and no callback values
4 - WAApplication>>handleFiltered: application URL with _s & _K
finish render
With iOS step 3 does not happen; I'd like to know what triggers it normally.
Just to add to the fun, we have a two WAApplication registered. The default application fails on iOS, the other works fine. I can see no obvious difference between the two.
Thanks for any help (I'll cross post on the the Seaside mailing list and Discord)
Problem is caused by a seven year old method that used a window.location.href= to gather device characteristics, like screen size and touch support. Removing that href fixes the problem with iOS. Lots of other & cleaner ways to get the data.
Quick fix is to wrap the href with a setTimeout for 200 ms.
Related
Problems
I'm using react-native for our current services, and we are sending cookies to our webpage to send information which is needed to seen in our webview. These process is working PERFECTLY in android devices, but not in IOS. (The most annoying thing is set-cookie works sometimes in IOS in same condition. It just randomly succeeded, and I cannot find the reason why.)
How To Reprouce
First of all, these are the stacks we are currently using.
Application: React-Native
Webview: react-native-webview (https://github.com/react-native-webview/react-native-webview)
Cookie: #react-native-cookies/cookies (https://github.com/react-native-cookies/cookies)
Webpage: React (Already deployed in AWS)
Cookie: react-cookie (useCookie)
And the following is our process we are currently doing.
If the user clicks a button (I will call this button as 'Apply' button), it navigates to screen that includes <WebView />
This is a abstract of our webview screen code (For our security issue, I just abstracted and changed some code for it, so if you think more information for our code, please let me know.)
Rendering Page
enter image description here
WebView Component
enter image description here
Send Cookie
enter image description here
Send Cookie Function
enter image description here
(This function is kinda messy bc this is a collective code from 3 files, and I tried my best to set cookie differently with android. (The same logic with android doesn't work in IOS))
Webpage (Launched in AWS)
enter image description here
I Want My Code To Do This
I want my code to send cookie in loading state, and after loading, when the webview rendered, the webpage get some cookie and based on that cookie, it shows some data.
It PERFECTLY works on Android, but not in IOS. It works randomly in IOS so I have no idea what the heck is wrong with this code and hard to define a problem.
I tried...
Someone said to me to add '.' infront of domain. It worked for the very first time, but after the second trial, it starts to not working again
I also tried clear all cookie data before set cookie using
await CookieManager.clearAll();
, but it works same as the first measure I tried.
I also tried to use webkit. I send all true arguments to use webkit while using cookiemanager, but it has no effect.
I expected to do...
As I write in the above, I hope the cookie is rightly set in both android and ios environment, perfectly works in both platform.
I'm developing an iOS application in which I want to provide users with a payment gateway, which is a web page. I'm showing this web page in a WebView.
The payment gateway accepts 2 URL params - success and failure URL, which are the URLs users is redirected to after completing purchase. Redirect is done via JavaScript location.href property and works properly in desktop browser and Android app.
I've set the URLs to let's say tft://redirect/success?id=123 resp. tft://redirect/failure?id=123
I want my app to handle this redirect and show Success or Failure message to user.
I followed many tutorials including Apple's docs.
First of all I'm not sure why Apple docs show scheme without slashes (myphotoapp: instead of myphotoapp:// - does it make a real difference?)
I've registered custom scheme tft and implemented the func application(..) function according to the docs.
Now when the redirect should happen, nothing really happens, the func application is not called at all.
I started development with iOS 12 and recently switched deployment target to 13.5, however, the project structure didn't change (scene delegate missing - is it an issue?).
Can you please give me any direction?
Thanks in advance.
According to https://stackoverflow.com/a/37240425/9046249 custom scheme behaves somewhat wierd. When I switched the scheme to http or https it works like a charm.
I have a single-page web app using Sencha Touch that has been added to the home screen on about 2000 iPads. I am looking to change the URL of the web app without requiring all of those users to delete the launch icon from the home screen, go to the new URL, and add it to home screen again. The app also uses a cache manifest to cache the HTML, CSS, JavaScript, and images, and the app is capable of working entirely offline.
Web pages added to home screen in iOS do seem to respond to HTTP 301 (permanent redirect) as expected, but I have found the behavior to be quirky in iOS 8 on iPad 2 devices as I will describe. I created an ASP.NET MVC website that I deploy under the same URL, replacing the Sencha Touch app in order to accomplish the permanent redirect. Here is the process I'm using and the behaviors I'm seeing:
When the app is launched from the old URL, it requests only the cache.manifest, and I return HTTP 404 to make the app stop caching.
The app loads and I have an event handler in the app's JavaScript for the applicationCache "obsolete" event that will call window.location.reload(true). The app will then reload and this time will ask for the previously cached HTML page (which is hosted at the URL root), and my ASP.NET MVC site will then return HTTP 301 to permanently redirect to the new URL.
Once the app hits the new URL, it begins downloading the resources from the cache.manifest at the new URL. I have an event handler on the "updateready" applicationCache event that will call window.location.reload(true) and reload the app. Once the app reloads, it will then request all resources (XHR requests to services) from the new URL as expected.
When I test this on an iPad 1 running iOS 5, this works exactly as I would expect. Once the resources from the new URL are downloaded and cached, it always makes every request from the new URL from that point. I can put the device in airplane mode and the app will work just fine offline.
This is where the quirky behavior begins, and I only see this on my iPads that are running iOS 8.x (I don't have any devices running iOS 6 or 7). I then close the app by pressing the home button and relaunch it from the home screen icon. When I relaunch the app, it will always initially go back to the old URL (iOS 5 always goes to the new URL), which is strange because the HTTP 301 from before should have prevented this. From here, there are two possible behaviors:
5a. Sometimes, it will ask for only the HTML page from the old URL (root URL), and in that case, it will get another HTTP 301 and will then redirect to the new URL, ask for the cache manifest, then load the app. From there and onward, it will never make requests to the old URL again when I open and close the app. When I put the device in airplane mode, the app works just fine offline. I have two iPad 2s running iOS 8.3 and 8.4, and this will happen about 50% of the time on these devices.
5b. Other times, it doesn't work so well. When relaunching the app after downloading the cached resources from the new URL, it will go back to the old URL and will not request the HTML page, and will instead request the cache.manifest along with the CSS and JavaScript. The the cache.manifest request will be result in another HTTP 404, but if I continue closing and re-opening the app, it will never consider the cache to be obsolete and will not request the HTML page again. Interestingly, I am only able to reproduce this on the iPad 2s. I have an iPad Air 1 running iOS 8.3 and I only ever see 5a on that device.
For the case described in 5b, it does request the JavaScript files. So, I went into one the JavaScript files and put in window.location.reload(true), which causes it to request the HTML page, which results in another HTTP 301. Now when this scenario occurs, it does send it to the new URL, but every time I close and re-open the app, it repeats the whole cycle. It goes to the old URL, gets the JavaScript, reloads, gets a 301, then goes to the new URL. When I put the device in airplane mode and open the app, it doesn't work.
I found that if I put the iPad 2s in airplane mode and run the app in the old URL, then run it again and do the 404 for the cache.manifest and the 301 for the HTML, then 5a will always occur. This sounds like a bug in iOS 8 (that possibly also exists in 6 and 7), and I'm trying to figure out a workaround that I can implement in my ASP.NET MVC website to redirect to the new URL that will work 100% of the time.
Any insights would be greatly appreciated.
I figured out how to avoid the quirky behavior. As I mentioned above, the app is listening to the "obsolete" event on applicationCache and is then calling window.location.reload(true) to grab the page again and get the 301. I found that if instead of reloading the same page, I redirect to a different page and back again, it works perfectly 100% of the time. It redirects to the new URL, caches the resources, then never asks for the old URL again. I also discovered that closing the app and opening it again after the cache is obsoleted has the same effect.
We are using Google Analytics to track events, but events don't appear to track 100% of the time. Sometimes they track, and sometimes they don't. We're not exceeding quota limits per session (at most we have 20 events per session). That shouldn't be the issue.
The tracking fails to work consistently on our normal website as well as our HTML5 mobile app version, though it's far less reliable with the HTML5 mobile app version.
Code:
var share_url = 'http://twitter.com/intent/tweet?text=';
// Log in GA
_gaq.push( ['_trackEvent', 'Share Twitter', ''] );
// Open URL in browser
open_external( share_url + encodeURIComponent( msg ) );
function open_external( url ) {
window.open( url + '#phonegap=external' );
}
_gaq.push( ['_trackEvent', 'Share Twitter', ''] );
This won't do anything.
For _trackEvent, the third argument (where you pass an empty string) is required. It's the 'Action' parameter. But an empty string is falsey, so it just fails silently.
Pass any value there, and it'll work.
Is this a reduced case? You shouldn't be seeing any events with that code.
Are you positive that you waited long enough for the data to be processed by Google? Especially since some tracking seems to be working.
I had the same behaviour (in a mobile app btw) but after waiting for more than a day it still came through. This still occurs on a daily basis... Hope this is the case for you too.
I'm not exactly sure what your problem can be, so I will throw some idea.
Most of them are obvious but it might help.
On your website:
Are you sure your embed the Google Analytics code snippet on every page who required tracking?
Load Google analytics from the asynchronous way.
On Google analytics check on Real time > Overview. As full report are delayed from few hours.
If you url is something like httq://localhost/ then your need to add the javascript code _gaq.push(['_setDomainName', 'none']); please read this post
It can't work with file:// url
(Probably not) Check if you can download the JavaScript from Google Analytics. Maybe your proxy block Google analytics tracking ?
In your application:
You are using embedded HTML 5 page within your app. So the way your open a page is using file://PATH_TO_MY_DIR/index.html as it's on your hard drive you can't send data to Google analytics.
As you are probably using PhoneGap, you need to "jump out" of your HTML page into native Objective-c code and send the event from your Objective-C code. Read Google Analytics and PhoneGap and this google group thread
Hope it help.
The problem is third parameter in:
_gaq.push( ['_trackEvent', 'Share Twitter', ''] );
The 2nd element of the array should be the category and the 3rd should be the action. For example:
_gaq.push( ['_trackEvent', 'Share', 'Twitter'] );
You can verify this yourself by pasting each of the above into your developer console (F12 in Chrome, Ctrl-Shift-K in Firefox) and watching the network traffic.
Reference:
https://developers.google.com/analytics/devguides/collection/gajs/methods/gaJSApiEventTracking
We already have Facebook working on our main desktop app without an issue. When I added the same setup code to our mobile site I received an error from the JavaScript SDK:
Received message of type object from https://s-static.ak.facebook.com, expected a string
Then, I changed the setup code to an exact replica from here: https://developers.facebook.com/docs/guides/mobile/web/ and received the exact same message.
This error only shows when the user-agent is iOS or Android in Chrome Developer Tools or in the iOS Simulator. When it's running from the desktop, we aren't seeing this error.
Any idea what's going on here?
Thanks :)
With all due respect, I believe that bokonic's answer is missing the point. The immediate reason of the message you're receiving is most likely javascript postMessage method. It is used to communicate your website with an object returned by window.open or an iframe's embedded website.
window.parent.postMessage(message, targetOrigin);
You might want to have a look at this article to see how it works.
According to MDN reference first argument of the postMessage method can be of any type. Still, Prior to Gecko 6.0 (Firefox 6.0 / Thunderbird 6.0 / SeaMonkey 2.3), the message parameter must be a string.
I tested the method on Chrome 28.0.1500.72 (latest version when writing this answer) and it works fine when passing an object but still throws the warning message to the console. I believe that facebook feels uncomfortable with passing some rich data as a string so they pass it as an object and simply doesn't care about the warning. Or, since there is a workaround (e.g. JSON.stringify), they have a bug they don't know about.
I had the same error. This isn't necessarily the reason you're getting it, but I ended up looking at the packets being received by my iphone simulator, and here's the error from s-statick.ak:
[truncated] <span>Given URL is not allowed by the Application configuration.: One or more of the given URLs is not allowed by the App's settings. It must match the Website URL or Canvas URL, or the domain must be a subdomain of one o
For me, the error is that on my device(s), I'm accessing the site through an ip address (192.168.xx etc) and on local development I have hosts routing localhost to a url that is in my facebook app config... so the IP isn't configured for the app.
Facebook won't let me use an IP address, so it seems like the only option is a test deploy or a DNS server. Hope this helps you out.