Huge Changes on Beta Server, Dev Implications?

It looks like there has been a massive change to the interface on the beta server, and as far as I can tell the realtime API is now completely gone. Furthermore, the application specific password feature in settings is no longer there, and my previously generated one comes back as unauthorized. Is there some big change in policy coming? What risks will I have to deal with as I am developing a client application?

1 Like

Pinging @anoek for this one.

2 Likes

Got a req into @matburt already to answer, we’ve been debating if the app specific password system is what should be done or not, he’s the mastermind behind that stuff though so he’ll be following up as time permits.

As for the real time API, it’s most certainly there, you just access it through the same IP as the main site now instead of the separate system (so just open up your websocket to beta.online-go.com and it should work just fine).

4 Likes

Thanks for clearing up the realtime server situation, for some reason it won’t show up in chrome developer tools no matter how I filter it. If I could make a suggestion, it would be very helpful for compatibility if you kept the ggs_host field in /ui/config, so that existing applications know where to look.

And for the password, does this mean I should use the same auth API as before, and just send the main website password in place of the app specific one? The oauth2/access_token API is returning not found.

edit: got chrome tools to see it, not sure what I did wrong before

1 Like

Sure, done.

3 Likes

It seems I can use api/v0/login and make requests by forwarding the returned cookies, for the time being it looks like I will have to do that to continue development.

edit: for future reference for other devs, the socket.io server config seems to have changed in beta, and it now gives a 400 bad request on connect if you don’t explicitly restrict the transport type to websocket.

Looks like the cookies won’t work after all, key APIs like challenge accept are refusing CSRFs from outside your domain. As it stands there seems to be no way for developers to use your API on the beta site.

There is a big change re the old application specific passwords is that we are dropping those in favor of just allowing the users to provide their password directly (which we didn’t allow in the previous version). There is also a 2-legged system that I think we’ll probably turn on also but in the meantime.

The token auth endpoint for the beta site is at https://beta.online-go.com/oauth2/token/ once you have defined a client.

We might still need to re-enable allowing CSRF for /api endpoints in general.

I tried with the client I configured on the previous version of the beta site, and it returned an invalid_client error, and https://beta.online-go.com/developer is an empty page. Is there another place to create a client?

@Almadiel The developer page is now live, on there is a link now to the oauth2 creation page, which is here: https://beta.online-go.com/oauth2/applications/

Sorry about the delay, there was some confusion about what needed to happen on my part

2 Likes

Thank you, it looks like its all working. Just wanted to be sure everything was good before 5.0 rolls out on the main site.

Though for accounts made by logging in with google or facebook, how can they authenticate through a third party client in the new system?