I'm trying to check if a url (in String form) returns 404 error. However, I can't seem to use java.net.URL, and I read somewhere that java.net is not supported in GWT? If so, how do I check if URL is dead or not in GWT?
Much appreciated.
You are right. In client side GWT you cannot use java.net.URL. Take a look at Google's JRE Emulation Reference if you are unsure what parts of the Java standard library can be uses with GWT.
Theoretically it would be possible to check a URL with an AJAX request (see RequestBuilder). But due to the same origin policy it is likely that the browser prevents such an attempt.
So I think you should implement the check on your applications server side (according to the link provided by Roflcoptr above in the comments) and call that routine with GWT-RPC.
Related
Following this post: http://android-developers.blogspot.com/2016/01/play-games-permissions-are-changing-in.html I have obtained a single use authorization code for use on my backend server as follows:
import com.google.android.gms.games.Games;
//later
Games.GetServerAuthCodeResult result = Games.getGamesServerAuthCode(gameHelper.getApiClient(), server_client_id).await();
if (result.getStatus().isSuccess()) {
String authCode = result.getCode();
// Send code to server...
This seems to works fine, but it presents a question:
1) getGamesServerAuthCode and GetServerAuthCodeResult are marked as deprecated. Why? Should I be using something else instead?
2) How would I do something equivalent in an non-Android installed Java application? I am able to obtain a token on the client application, but I also need to obtain a single use code to pass to my backend server like above. I can't find an equivalent function to get a Server Auth Code. (using com.google.api.client.extensions.java6.auth.oauth2)
I am basically trying to follow this flow: https://developers.google.com/games/services/web/serverlogin but in Java, NOT Javascript. I am attempting to do this in an Android app and a desktop Java app.
1) Yes, in Android use GetServerAuthCodeResult although it is still marked as deprecated. It is the recommended way from Google and it seems they have only forgot to remove the deprecation annotation when releasing to general public.
2) For desktop applications you can follow the instructions here: https://developers.google.com/identity/protocols/OAuth2InstalledApp
Basically from your app you open the system browser (embedded webviews are discouraged) and make a https request to the https://accounts.google.com/o/oauth2/v2/auth endpoint. In the request you supply a local redirect URI parameter i.e. http://127.0.0.1:9004 (you should query your platform for the relevant loopback IP, and start a HTTP listener on a random available port). The authorization code will be sent to your local HTTP listener when the user has given consent or an error such as error=access_denied if the user declined the request. Your application must be listening on this local web server to retrieve the response with the authcode. You also have the option to redirect to a server URI directly claimed by your app, see docs on link above. When your app receives the authorization response, for best usability, it should respond with an HTML page, instructing the user to close the browser tab and return to your app. Also, if you want the Games-scope make sure you are using the https://www.googleapis.com/auth/games as scope in the request, example below, with line breaks and spaces for readability.
https://accounts.google.com/o/oauth2/v2/auth?
scope=https://www.googleapis.com/auth/games&
redirect_uri=http://127.0.0.1:9004&
response_type=code&
client_id=812741506391-h38jh0j4fv0ce1krdkiq0hfvt6n5amrf.apps.googleusercontent.com
Please note that I think you'll have to create and link an app of type other, in the Google Play Developer Console linked-app, for the localhost redirection to work. Use type Web if you plan to redirect to server URI directly, add your server URI to Authorized redirect URIs in the API Manager under section Credentials.
Browser screenshot:
There is finally a proper answer to part 1) of this question!
In the release notes of gms 10.2.0
https://developers.google.com/android/guides/releases#february_2017_-_v102
the new method of obtaining a server code is described. A good example of how to do this is provided here:
https://github.com/playgameservices/clientserverskeleton
I ended up updating Google's baseGameUtils to follow the example above.
Still not sure the proper way to do this for part 2) of the question, at the moment I am sending the token to the server which works but is probably unsafe.
I trying to automate few things in my workplace where we are not allowed to use internet (Not all website very few allowed).
Req: I have a form which has a single text box & a single submit button, I have to put something in the text box and submit the form. The response I need to parse the HTML and get a specific text. The pages are written in JSP
Constraint: I don't have access to third party libraries & have to work with Java 6.
Please put me in right direction.
HttpURLConnection comes default with java. You may consider using this API. This API does most of the functionality as Apache HTTPClient. Here is simple example on how to use HTTPURLConnection.
I would use something like tamperdata from Firefox to capture the HTTP request that gets sent to the server, and then use HTTPUrlConnection (part of the JDK) to re-create that request.
This question already has an answer here:
How reliable is HTTP_REFERER?
(1 answer)
Closed 8 years ago.
I am interested in logging from where a user comes in order to access my web app.
I thought of using HTTP's referrer header for that, but from e.g.HTTP referrer wiki
it seems that this is not a accurate/reliable way since in many cases it is not send.
I was wondering is the referrer header the only way? Is there a better/standard approach?
Reliable way would be to have ?ref=somehash a GET parameter
For example:
Consider this site SO, they have list of questions, now there is a portlet which streams the recent questions to some other site for example abcd.com now to see if user clicked the link from abcd.com you pass a parameter ?ref=423jahjaghr where this string maps to abcd.com
Referrer header isn't the only way, but it is the most standard.
You can consider using Google Analytics, which has extra referrer capabilities, but you'd have to manually setup collecting the data from their services to input into your logging infrastructure.
Nothing is going to be 100% fool proof though. It's pretty straight-foward to block Google Analytics, and spoof referrers, and HTML5 will make it even easier to prevent sending referrer information.
If it's mission critical that you know the referrer of all inbound traffic, you'll have come up with a more draconian approach (like #Jigar Joshi has suggested)
Depending on the browser, you may OR may not get the referrer header. You may not get it always. You have to have a request parameter OR a form field to get the referrer.
HTTP Referer is a good way to analyze logs. And to maintain analytics on user interactions. However a browser or any other system which displays webpages and is able to traverse a webpage might not send this header entry.
You might also consider to use a 3rd party application like google analytics. But you should check if this 3rd party tool is legal in your country. Most of them have data-privacy issues.
Very important is. For analytics its ok if you have a certain error in the expected outcome. However never do any security related checks on the http referer. Someone might enter whatever he wants as referer.
Im trying to use DefaultHttpClient to log into xbox.com. I realize that you cant be logged in without visiting http://login.live.com, so I was going to submit to the form on that page and then use the cookies in any requests to xbox.com.
The problem is that requesting anything from live.com using DefaultHttpClient returns the followings message.
Windows Live ID requires JavaScript to sign in. This web browser either does not support JavaScript, or scripts are being blocked.
How do I tell DefaultHttpClient to tell the server that javascript is available for use? I tried looking in the default options and also adding it as a parameter object but I cant see what I've got to do.
The reason this is happening is that this line of HTML is getting parsed from live:
<noscript><meta http-equiv="Refresh" content="0; URL=http://login.live.com/jsDisabled.srf?mkt=EN-US&lc=1033"/>Windows Live ID requires JavaScript to sign in. This web browser either does not support JavaScript, or scripts are being blocked.<br /><br />To find out whether your browser supports JavaScript, or to allow scripts, see the browser's online help.</noscript>
Which is used to redirect you if your client does not have javascript enabled (and therefore will parse <noscript> tags.)
You could try to use a less intelligent HTTP library which does no parsing of the content, but which instead simply does the transport and leaves the parsing to you.
Use Wireshark to trace the communication using both a browser and your program, and look for the differences. It's hard to say what, exactly, live.com/xbox.com are looking for, but there is likely some AJAX-y code used to get the actual content.
Windows Live ID requires JavaScript to sign in. This web browser either does not support JavaScript, or scripts are being blocked.To find out whether your browser supports JavaScript, or to allow scripts, see the browser's online help.
This problem relates to the Restlet framework and Java
When a client wants to discover the resources available on a server - they must send an HTTP request with OPTIONS as the request type. This is fine I guess for non human readable clients - i.e. in code rather than a browser.
The problem I see here is - browsers (human readable) using GET, will NOT be able to quickly discover the resources available to them and find out some extra help documentation etc - because they do not use OPTIONS as a request type.
Is there a way to make a browser send an OPTIONS/GET request so the server can fire back formatted XML to the client (as this is what happens in Restlet - i.e. the server response is to send all information back as XML), and display this in the browser?
Or have I got my thinking all wrong - i.e. the point of OPTIONS is that is meant to be used inside a client's code and not meant to be read via a browser.
Use the TunnelService (which by default is already enabled) and simply add the method=OPTIONS query parameter to your URL.
(The Restlet FAQ Q19 is a similar question.)
I think OPTIONS is not designed to be 'user-visible'.
How would you dispatch an OPTIONS request from the browser ? (note that the form element only allows GET and POST).
You could send it using XmlHttpRequest and then get back XML in your Javascript callback and render it appropriately. But I'm not convinced this is something that your user should really know about!