• Join - It's Free

Bug in sandbox?

Started by Private User on Wednesday, August 12, 2020
Problem with this page?

Participants:

Profiles Mentioned:

  • Private
    Geni member

Related Projects:

Showing all 19 posts

For testing the software I am developing I am using the sandbox (so real fire will ALWAYS be bullet proof).

I am trying to write a unittest for checking and identifying profiles which were merged. So I merged a profiles and read using the usual interface:

https://sandbox.geni.com/api/profile-g13259711?access_token=MY_ACCE...

But it fails giving strange errors:

ssl.SSLError: [SSL: TLSV1_UNRECOGNIZED_NAME] tlsv1 unrecognized name (_ssl.c:748)

Actually, I noticed that, in the database, the profile apparently changed the name:

https://sandbox.geni.com/people/Sister-Profile/13259711

by:

https://sandbox.geni.com/people/no-name/13259711

Which is not happening in production version (they keep their original name), so it is a different behavior between production and sandbox and likely an small bug.

This is not really blocking me, but I would like to avoid using production for testing.

There is an error in your API call: remove the character g before profile ID from your API call. It is used with profile GUID, not with profile ID.

I think the g prefixis correct. That is a guid he's referencing.
The calls reference sandbox.

I think the SSL error you're getting is because your root certificates are not
up to date.

Thanks for trying to support me here.

In fact, what I am trying to do is to create a unittest code including a profile that has been merged, trying to test the case when a profile is merged an dissapears pointing our to another profile.

My unittest library is quite extensive, and I am quite sure the way I am using ID is the correct one. Also all the other tests works but this one.

In particular, what I did for my testing is to merge the profile "MERGED"

https://sandbox.geni.com/people/Sister-Profile/13259711

into the profile "ORIGINAL", which remains

Private

If you go into the sandbox to "ORIGINAL" it looks a normal profile, if you go to "MERGED" you will receive the usual message that it has been merged.

So, what I tried to do is to call both profiles with the API:

"MERGED"
https://sandbox.geni.com/api/profile-g13259711?access_token=MY_TOKEN
"ORIGINAL":
https://sandbox.geni.com/api/profile-g1150209?access_token=MY_TOKEN

So, using the API, "MERGED" fails with an SSL error but "ORIGINAL" works.

So, if "ORIGINAL" works, that means that the problem is not the "g", as well, it proves that the root certificates are ok, as working for "ORIGINAL".

That's why I think that there is likely a bug in the server code.

More explicitly, if you are authenticated in your browser and use that authentication to use the API so, I introduce in my browser the following:
"MERGED"
https://sandbox.geni.com/api/profile-g13259711
"ORIGINAL"
https://sandbox.geni.com/api/profile-g1150209

Both of them work! (which discards also the "g" issue). So the problem is specific to the authentication method that I am using.

Actually, the output from "MERGED" is what I am looking for. The key "merged_into" is telling me the new profile it is linked (in API id)

Btw... I have always struggled to understand the software design principle to store 2 different ID for profiles....

Thanks again.

Btw, I have noticed a bug in the website of GENI.

If I introduce a sandbox profile which has a profile with the same id inside production, it transforms the profile into the production one.

In particular, in my text above I wanted to introduce the following profiles (I have introduced spaces to avoid the conversion):

https:// sandbox.geni.com/ people/ Sister-Profile/ 1150209

but actually (if I remove spaces is doing this:

Private

Which points to this profile

https:// www.geni.com/ people/ private/ 1150209

Do the failing requests work for you if you don't use your access token?

Well, I tested just in case, but without authentication method I cannot access to the information of the profile.

So it works (and does not provide the SSL error), but provides few information as profiles are private and I do not have access to the info.

So...

Sorry, I've been busy.

I don't know why passing an access token would cause SSL to fail.

Can you try it a couple of more times so I can get some logs.

Done!

I have it in a dedicated unittest, I can reproduce on demand.

It is a test that was working several weeks ago

The requests seem fine.
Is there any way you can turn on protocol logging for your test?

How can I do that?

I'm not familiar with python, but you can try this curl command

curl -iv <url>

Does not work... it looks an issue from the server

btw, 4 months and still open.

Can you paste the results for the curl command I posted earlier?

Well... now that the database has been killed completely might have differen behaviour...

I made the connection

Microsoft Windows [Versión 10.0.18363.1198]
(c) 2019 Microsoft Corporation. Todos los derechos reservados.

C:\WINDOWS\system32>curl -iv Private
* Trying 45.60.65.253...
* TCP_NODELAY set
* Connected to sandbox.geni.com (45.60.65.253) port 443 (#0)
* schannel: SSL/TLS connection with sandbox.geni.com port 443 (step 1/3)
* schannel: checking server certificate revocation
* schannel: sending initial handshake data: sending 181 bytes...
* schannel: sent initial handshake data: sent 181 bytes
* schannel: SSL/TLS connection with sandbox.geni.com port 443 (step 2/3)
* schannel: encrypted data got 3664
* schannel: encrypted data buffer: offset 3664 length 4096
* schannel: sending next handshake data: sending 93 bytes...
* schannel: SSL/TLS connection with sandbox.geni.com port 443 (step 2/3)
* schannel: encrypted data got 258
* schannel: encrypted data buffer: offset 258 length 4096
* schannel: SSL/TLS handshake complete
* schannel: SSL/TLS connection with sandbox.geni.com port 443 (step 3/3)
* schannel: stored credential handle in session cache
> GET /people/Sister-Profile/1150209 HTTP/1.1
> Host: sandbox.geni.com
> User-Agent: curl/7.55.1
> Accept: */*
>
* schannel: client wants to read 102400 bytes
* schannel: encdata_buffer resized 103424
* schannel: encrypted data buffer: offset 0 length 103424
* schannel: encrypted data got 770
* schannel: encrypted data buffer: offset 770 length 103424
* schannel: decrypted data length: 741
* schannel: decrypted data added: 741
* schannel: decrypted data cached: offset 741 length 102400
* schannel: encrypted data buffer: offset 0 length 103424
* schannel: decrypted data buffer: offset 741 length 102400
* schannel: schannel_recv cleanup
* schannel: decrypted data returned 741
* schannel: decrypted data buffer: offset 0 length 102400
< HTTP/1.1 500 Internal Server Error
HTTP/1.1 500 Internal Server Error
< Server: nginx
Server: nginx
< Date: Mon, 04 Jan 2021 21:19:20 GMT
Date: Mon, 04 Jan 2021 21:19:20 GMT
< Transfer-Encoding: chunked
Transfer-Encoding: chunked
< Connection: keep-alive
Connection: keep-alive
< Set-Cookie: visid_incap_527931=VEBFkCOHSD+ZWZFRgz3uFFeG818AAAAAQUIPAAAAAABh2spfWkfveW4EVYjJ5veE; expires=Tue, 04 Jan 2022 16:53:19 GMT; HttpOnly; path=/; Domain=.geni.com
Set-Cookie: visid_incap_527931=VEBFkCOHSD+ZWZFRgz3uFFeG818AAAAAQUIPAAAAAABh2spfWkfveW4EVYjJ5veE; expires=Tue, 04 Jan 2022 16:53:19 GMT; HttpOnly; path=/; Domain=.geni.com
< Set-Cookie: incap_ses_1393_527931=3XPyUbF0y1jhZmcbIe5UE1eG818AAAAACE9XNdAbhTP9I5xWpkcGaQ==; path=/; Domain=.geni.com
Set-Cookie: incap_ses_1393_527931=3XPyUbF0y1jhZmcbIe5UE1eG818AAAAACE9XNdAbhTP9I5xWpkcGaQ==; path=/; Domain=.geni.com
< Set-Cookie: ___utmvmmNBupoca=zMMZBjTeynS; path=/; Max-Age=900
Set-Cookie: ___utmvmmNBupoca=zMMZBjTeynS; path=/; Max-Age=900
< Set-Cookie: ___utmvamNBupoca=omVgLZM; path=/; Max-Age=900
Set-Cookie: ___utmvamNBupoca=omVgLZM; path=/; Max-Age=900
< Set-Cookie: ___utmvbmNBupoca=sZE
Set-Cookie: ___utmvbmNBupoca=sZE
< XJlOmalX: rtO; path=/; Max-Age=900
XJlOmalX: rtO; path=/; Max-Age=900
< X-CDN: Incapsula
X-CDN: Incapsula
< X-Iinfo: 14-255005361-255005383 NNNN CT(96 198 0) RT(1609795159337 112) q(0 0 3 1) r(4 4) U5
X-Iinfo: 14-255005361-255005383 NNNN CT(96 198 0) RT(1609795159337 112) q(0 0 3 1) r(4 4) U5

<
* schannel: client wants to read 102400 bytes
* schannel: encrypted data buffer: offset 0 length 103424
* schannel: encrypted data got 34
* schannel: encrypted data buffer: offset 34 length 103424
* schannel: decrypted data length: 5
* schannel: decrypted data added: 5
* schannel: decrypted data cached: offset 5 length 102400
* schannel: encrypted data buffer: offset 0 length 103424
* schannel: decrypted data buffer: offset 5 length 102400
* schannel: schannel_recv cleanup
* schannel: decrypted data returned 5
* schannel: decrypted data buffer: offset 0 length 102400
* Connection #0 to host sandbox.geni.com left intact

C:\WINDOWS\system32>

I have been able to reproduce the error in the new sandbox with new data.

Now the existing profile is:

https://sandbox.geni.com/people/Sister-Profile/330428

and the merged profile is:

https://sandbox.geni.com/people/Sister-Profile/330434

When trying to use the API to get the profile https://sandbox.geni.com/people/Sister-Profile/330434 it fails.

It is not a connectino problem, so I do not understand the test above. If I would have had a connection problem why the first profile is working and the production server is working perfecly wiht this kind of issue?

One thing I noticed is that https://sandbox.geni.com/people/Sister-Profile/330434 isn't an API call, you're just talking to the regular site at that point. The regular site uses a session cookie to authenticate. Passing an access_token to a URL other than /api won't work.

Our logs show that that your calls to /api/profile-g330434?access_token=... are working
Your calls to /people/Sister-Profile/330434 are returning the private profile because you are not considered logged-in.

Showing all 19 posts

Create a free account or login to participate in this discussion