search

sanvlr12 / google-api-dotnet-client

Automatically exported from code.google.com/p/google-api-dotnet-client
0 stars 0 forks source link

Google Latitude Authorization Request exception. #137

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Accessing Latitude Service using WCF Service
2. ASP.NET aspx is the client/consumer

*** I implemented the ASP.NET application for Latitude service and it is 
working absolutely fine. But when I shifted code to WCF so that any one can use 
it as a service. I got one error. May be my code fault. 

The code: in method: 
private IAuthorizationState GetAuthorization(WebServerClient client)
{}

code:  
string scope = LatitudeService.Scopes.LatitudeCurrentCity.GetStringValue();
OutgoingWebResponse response = client.PrepareRequestUserAuthorization(new[] { 
scope });
response.Send();

this response.Send() is throwing exception [type is native optimized exception, 
so cant trace).

What version of the product are you using? On what operating system?
ANS: Windows Server 2003 Enterprise SP2

- Regards,
Soumen Dey, India, rimbik@gmail.com

Original issue reported on code.google.com by rim...@gmail.com on 5 Sep 2011 at 9:06

Attachments:

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago 
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:

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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:

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago

Original comment by asky...@google.com on 3 Oct 2011 at 11:53