Closed GoogleCodeExporter closed 9 years ago
Hi,
We are going to need a bit more in the way of details here, could you please
provide the exception and stack trace you receive.
Looking at the attachment it appars you are using the ClientCredtials class
provided to keep our samples simple please note from its comments
/// <summary>
/// This class provides the client credentials for all the samples in this solution.
/// In order to run all of the samples, you have to enable API access for every API
/// you want to use, enter your credentials here.
///
/// You can find your credentials here:
/// https://code.google.com/apis/console/#:access
///
/// For your own application you should find a more secure way than just storing your client secret inside a string,
/// as it can be lookup up easily using a reflection tool.
/// </summary>
So please make sure you have got your api key and secret from the developers
console and place these in this file. If this runs you've found your problem
and then you will need to store these values in a secure manner.
Original comment by davidwat...@google.com
on 6 Sep 2011 at 10:59
First of all many thanks for your reply.
To clarify, yes I have created my KEY and other details as follows using Google
API console and configured my credential accordingly:-
Client ID:
87348938769-sa3bdqsd3dr34fq792ko0urf9kflmpeh.apps.googleusercontent.com
Client secret:XbzLTJtNUdLyrE_TfuJQ6-ez
Redirect URIs:http://localhost:2724/GoogleAPI.svc
JavaScript origins:http://localhost:49325
AND ALSO:
API key:CIzASyAeULIpjKERimBikNlmMiCUWqrtSizVqCo
Activated on:Sep 2, 2011 3:00 AM
Activated by:rimbik@gmail.com – you
The above information are modifed for security reason and to update that I have
set all those.
And further more, I can execute and get my perfect data while using the same
code and credential using ASP.NET and direct use of API in it.
But no luck for WCF where ASP.NET is the consumer. In this case I use the WCF
service url for generating the Client-ID.
- Regards,
Soumen Dey, rimbik@gmail.com
Original comment by rim...@gmail.com
on 6 Sep 2011 at 1:54
Attachments:
Hello,
The type of the exception is ThreadAbortException, which indicates that your
thread is being aborted before that call completes. Is it possible that the
timeout for your WCF call is shorter or the call is blocking?
Original comment by asky...@google.com
on 6 Sep 2011 at 8:40
the .Send method throws an ThreadAbortException to prevent ASP.NET from sending
a normal/second HTTP response; so it is thrown by design there. I have no idea
what the correct implementation for using it with WCF is, though.
Original comment by mlinder...@gmail.com
on 6 Sep 2011 at 8:48
What I have observed while debugging that.
For ASP.NET, The API behaves as follows:-
1. While PageLoad() in ASPX,
a. Create service instance
b. set it in Session
2. Now you see the Web Page and Clicks <<Aythenticate>>
a. It throws the same 'ThreadAbortedException' as shown as error above
(the exception we logged)
b. Takes you to Google Login Page
*** Remember this Exception is normal, even for working ASP.NET code
and same is happeing with WCF as well
3. After successfull login in google, and branding page
a. you come back to ASPX page once again with new buttons like:
[Get Current Location]] say for example
So, these three steps are absolutely mandatory
But the case is not same for WCF as like in Step-2 above, it executes Step-2.a
and then no where and hangs.
Note: I close the Web Server and delete cookies, session from IE each time I
start fresh debugging.
- Regards,
Soumen Dey
Original comment by rim...@gmail.com
on 7 Sep 2011 at 11:51
This is to further update:
the response object from:
OutgoingWebResponse response = client.PrepareRequestUserAuthorization(new[] { scope });
Gives the attached response text and while looking into it, identified even
though I am using different Redirect URIs: http://localhost:2710/Default.aspx
(seted in API Console)
it still uses GoogleAPI.svc as seen in attached image. Why So?
Regards,
Soumen Dey
Original comment by rim...@gmail.com
on 7 Sep 2011 at 12:33
Attachments:
Try handing over an IAuthorizationState to the WebServerClient. The
IAuthorizationState class has a .Callback property, which can be used to set a
custom redirect URL.
So the code should look something like this:
var state = new AuthorizationState(new[] { scope });
state.Callback = "Http://___:2710/Default.aspx"
var response = client.PrepareRequestUserAuthorization(state);
Original comment by mlinder...@gmail.com
on 12 Sep 2011 at 4:48
Original comment by asky...@google.com
on 3 Oct 2011 at 11:53
Original issue reported on code.google.com by
rim...@gmail.com
on 5 Sep 2011 at 9:06Attachments: