Since iOS 7 blocked the spoofing of http://www.apple.com/library/test/success.html I am looking for another way to block the Captive Network Assistant login page. Since Apple has the devices checking 1->m websites I can not be sure all are blocked on the company's open network.
If there is no way to block it I would be open to changing it to a webpage with an accept button, like a terms page, but I can not find a method to do that either.
Since IOS7 apple now test more than 200 random URL too see if its on internet, you can not open for one and one page.
The way to handle this is to create a filter that looks for User Agent UA CaptiveNetworkSupport.
If portal sees this, it should return Success back to client.
User Agent:
CaptiveNetworkSupport
HTTP header:
HTTP/1.1 200 OK
Content-Type: text/html
Connection: close
Vary: Accept-Encoding
HTTP Response:
<HTML><HEAD><TITLE>Success</TITLE></HEAD><BODY>Success</BODY></HTML>
On thing you might try, is always redirecting to a https page, the Captive Network Assitant expects a 302 redirect to a http url.
So, if whenever an http request comes in on your captive portal, you return a 302 redirect to an https page, the CNA won't appear.
Example request
Request URL:http://www.somepage.com
Request Method:GET
Response Headers Contain:
...
HTTP/1.1 302 Hotspot redirect
Location:https://www.mycaptiveportal.com
...
Following this post: Facebook.com and the iOS7 Captive Portal Detection
The IOS 7 devices check for the following domains:
www.appleiphonecell.com
captive.apple.com
captive.apple.com
www.apple.com
www.itools.info
www.ibook.info
www.airport.us
www.thinkdifferent.us
So if you'd open(unblock) those domains (like you did before with the success page), it should revert to the old behaviour.
However, there are also rumors that Apple now checks about 200 domains (which would then make these domains irrelevant), but i did not see confirmation of that.
I hope this helps.
Regards,
Related
I have two request in 1st request is giving me 307 redirect along with location header.
I pull Location header from response headers of 1st request and then passed it to second request.
Now 2nd request is giving me 302 every time.
I tried to play with follow request / redirect automatically options in 1st and 2nd request. However it didnt help. I checked both requests shows Https, I checked cache manager it is working fine.
Played with some settings related to Cache Control still issue is occurring.
2nd request is responsible for generating phpsessionid as 'set-cookie' which will only come when 200 OK will happen.
If anyone has any workaround, please assist. Thanks.
As per HTTP Status 302
The HyperText Transfer Protocol (HTTP) 302 Found redirect status response code indicates that the resource requested has been temporarily moved to the URL given by the Location header. A browser redirects to this page but search engines don't update their links to the resource (in 'SEO-speak', it is said that the 'link-juice' is not sent to the new URL).
so my expectation is that you need to play the same trick as with the 1st request, to wit extract the redirect URL from the Location header and add 3rd HTTP Request sampler to hit that URL
In general a "good" JMeter test should behave exactly like a real browser so you should cross-check JMeter's network footprint with what is in the "network" tab of your browser developer tools and amend JMeter's configuration so it would send exactly the same requests as the browser does.
What I am using OAuth to authenticate with Microsoft:
https://login.microsoftonline.com/common/oauth2/v2.0/authorize...&redirect_uri=MYURL
(I also use similar approach with google: https://accounts.google.com/o/oauth2/v2/auth...redirect_uri=MYURL)
MYURL is https://admin.myrealdomain.com/code
(MYURL is an empty 200 Ok page on my server)
However, Microsoft Graph returns with 302 redirect from https://login.live.com/oauth20_authorize.srf...
and this causes issues with deeplinks handling (the page just is not intercepted by the app).
I don't have any such issues with Google though (200 status code).
And it seems like it recently worked just fine with Microsoft as well. I am just not sure if this is something I miss or MS has some recent changes applied to that logic.
Does anyone has any idea how I can solve it? Thanks!
It seems that you are executing the OAUTH code flow behind the scenes. It doesn't work this way.
You should pop up a browser dialog to request the authorization code. See reference here.
The steps:
Pop up a browser dialog which the url address is
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?...
After User signs in, it redirects to the redirect url, where the
authorization code has been returned.
POST to
https://login.microsoftonline.com/common/oauth2/v2.0/token?....
you can get the access token to call Microsoft Graph API.
In windows 8 metro app if i send a winjs.xhr (ajax) request to http://abc.com
and that domain's response is auto redirect 302 to to http://xyz.com,
then winjs automatically follows the redirect and comes with the result of xyz.com (2nd domain), i want to stop the behavior and read the response i get from I st request before the redirect.
WinJs.xhr is simple wrapper around XMLHttpRequest and that needs to comply with W3C standard
(https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#infrastructure-for-the-send%28%29-method), and according to it redirects are transparent.
If the response is an HTTP redirect:
If the origin of the URL conveyed by the Location header is same origin
with the XMLHttpRequest origin and the
redirect does not violate infinite
loop precautions, transparently
follow the redirect while observing
the same-origin request event rules.
In Win 8.1 MS introduced Windows.Web.Http.HttpClient also available for WinJS, which has more configuration options so that might be solution for you.
My company is embarking on a large website redirection at the moment and I decided it would give us the perfect opportunity to make the URL's more user and google friendly.
To give you a brief outline of the situation, I am the SEO guy and I am dealing with an external developer in order to redirect the website without hurting the current rankings in Google. I don't have much experience regarding sharepoint hence why I would really appreciate any assistance in understanding and knowing if there is a work around to my situation.
The website is using IIS7.5, they recently installed the URL Rewrite Module in order to create more user friendly URL's. My question is, by creating a more user friendly URL, does this cause an additional redirect?
For example: if a user types in www.domain.com this permanently (301) redirects to www.domain.com/pages/home.aspx.The developer told me that in order to rewrite the URL to display something more friendly (like www.domain.com/home) this will have to cause another permanent redirect. So in essence the process will look like this:
REQUESTING: http:// www.domain.com
SERVER RESPONSE: HTTP /1.1 301 Redirect
1) Redirecting to: http:// www.domain.com/pages/home.aspx
SERVER RESPONSE: HTTP /1.1 301 Redirect
2) Redirecting to: http:// www.domain.com/home
SERVER RESPONSE: HTTP/1.1 200 OK
Is this how the URL Rewrite Module really works? I would have thought that it would not have to create another redirect in order to create a more user friendly URL?
My second problem is this.... The redirect is happening on the same server. So here is essentially the situation:
www.old-domain.com
www.dev-domain.com
www.new-domain.com
The old-domain needs to be redirected to the new domain so we ran a test in order to see if the HTTP status codes were correct before going ahead with the project. So the developer redirected the dev-domain to the new-domain and the redirects look like this: (The developers comments in italic below)
REQUESTING: http:// www.dev-domain.com
SERVER RESPONSE: HTTP/1.1 301 Moved Permanently
1) Redirecting to: http:// www.new-domain.com/
SERVER RESPONSE: HTTP/1.1 302 Redirect
2) Redirecting to: http:// www.dev-domain.com/Pages/home.aspx
SharePoint’s alternate access mappings causes this to happen and there is no way around this.
SERVER RESPONSE: HTTP/1.1 301 Moved Permanently
3) Redirecting to: http:// www.dev-domain.com/pages/home.aspx
SERVER RESPONSE: HTTP/1.1 301 Moved Permanently
4) Redirecting to: http:// www.new-domin.com/pages/home.aspx
SERVER RESPONSE: HTTP/1.1 200 OK
The developer states the reason for redirecting back to the dev-domain then back to the new-domain is because of SharePoint's alternate access mappings and there is no way around this. Is that entirely true?
Any assitance at all will be GREATLY appreciated!
I'm trying to pass some variables to my facebook app from the url, i.e. using GET variable app_data like facebook wants.
At some point I've stopped getting the ['signed_request'] part of the $_REQUEST. When I print_r($_REQUEST) I'm getting: ['doc'], ['user'], ['__utmz'], ['__utma'] and ['session'] values, but not signed request :(
Any ideas of why this might be happening?
Check the tab/canvas url is EXACTLY the same as required. If there is a redirect to another page, then signed request and other values will not be sent. You can check using a browser sniffer, if a call to the page responds with a 300 (301/302 etc) redirect, then you need to change to what it redirects to.
Examples:
https://example.com/ may need to be https://www.example.com/ (add www., or remove www. depending on how server is set up)
www.example.com/ may need to be www.example.com/index.php (add index.php, or the right page).
Check you are using http:// and https:// correctly in the URLs, and that https:// returns a valid page.
I've only been able to get the signed request in https://, i get no request at all in http.
Currently have a bug on FB, but no word on fixing it yet; http://developers.facebook.com/bugs/264505123580318?browse=search_4eb3ef23eb18d6649415729
EDIT:
http://SITE.com was redirecting to http://www.SITE.com, so I was loosing the request variables.
Had a similar issue, for me it was as simple as a mismatch of the app id and app secret! However in facebook developers backend I have noticed that the URLs all need to have that trailing slash!
Some browsers do redirect your request to https automatically if you have been on this particular site on https so if you are in http mode on facebook there is situation:
facebook requests http version of your app, browser redirect this request of facebook to https and POST data and thus signer_request are gone in this process...
i see this problem in chrome 23, if you delete browsin data (particulary Deauthorize content licenses) app should run back on http