Neowin External Login Tool

[matt74441]

He used the VB code for the Neowin Assistant program that he wrote.

[+chorpeac MVC]

He used the VB code for the Neowin Assistant program that he wrote.

And what does that do? :huh:

Sorry, never heard of it.

[matt74441]

https://www.neowin.net/forum/index.php?showtopic=185472

[+chorpeac MVC]

https://www.neowin.net/forum/index.php?showtopic=185472

Ah yeah, I remember reading about this.

Thanks matt.

[Glowstick]

Nope, we implemented it in this form for a reason. No one can have you enter your password and harvest the result for malicious purposes. How do we know that you're not also having your application send the login data to your own server for collection and future abuse? We just cannot give out automated trust.

With SOAP webservice I meant more accessing Neowin features like PMs, news and what not. The SOAP service would use a ticket emitted by the server (tho it'd need a way higher timeout, like 5 mins). The ticket would still have to be retrieved by site, a .NET library for such a job could do this with an IE control.

[Tim Dorr Veteran]

With SOAP webservice I meant more accessing Neowin features like PMs, news and what not. The SOAP service would use a ticket emitted by the server (tho it'd need a way higher timeout, like 5 mins). The ticket would still have to be retrieved by site, a .NET library for such a job could do this with an IE control.

Now you're talking ;)

I'll see what I can cook up for that. Luckily, I'm not a stranger to SOAP in PHP :)

[Tim Dorr Veteran]

https://www.neowin.net/forum/index.php?showtopic=185472

I'd just be wary as that may break over time, but this will always be supported. And if we can get the SOAP interface all set with the ticket, then there's no reason *not* to use this :)

[matt74441]

Well thanks again Tim for this wonderful script that you wrote. Its now fully integrated into Neomap, and is working perfectly.

[Glowstick]

Idea about how authentication could work for a SOAP service:

External browser (paranoia auth):

I didn't fiddle too much with browser controls hosted in applications, but there might be the possibility that you can access the password fields using the DOM, so you need an external method.

Optimal case would be that the application triggers a browser to pop up, by using an URL that contains a session ID (RNG'd by the application). Like:

https://www.neowin.net/soapLogin.php?sid=123456789abcdef123456789abcdef

This would cause a login window to show up in the started browser, and when the login succeeds, it'll store the session on the server including the originating IP address (I suppose you'll be using a seperate session table for SOAP things). The application would poll the server in 5-15sec timespans and monitors the authentication state, by calling a simple URL and returning the text returned (soapAuthState.php?). States returned could be:

- No session / AUTH_NOSESSION

- User is authenticating / AUTH_PENDING

- User authenticated / AUTH_OK:<sidhere>

- Login attempt failed (Application should treat this as login typo) / AUTH_FAILED

- 5 login attempts failed, blocked for 30/60mins / AUTH_BLOCKED:<remainingtimeinsechere>

On successful authentication, the application can use the session ID (or a CRC32 of it, would be faster serverside) sent during the authentication process to perform different SOAP jobs.

The session ticket timeout should be reset when a SOAP function is called (either some specific SOAP job or a plain SOAP refresh function), otherwise it should timeout after 5/10mins.

The HTML for the login window should use JScript to resize itself and emulate a small login window instead of hogging screenspace.

Would be nice to have a SOAP service by the time the Longhorn beta goes to the wide public, regarding sidebar tiles and what not.

[JMann Veteran]

Holy cow. :)

[john smith 1924 Veteran]

i think that is a nice idea Tom - i'd think it might be better managed through IVB - have you tried / proposed it there?

[The_Decryptor Veteran]

I like the idea of a neowin web service, send pm's and reply to topics and other stuff (like performing searches and having the data returned as a .NET DataGrid component, or as any custom xml schema) from any device that supports web services

I also like the idea of a web based login hosted on the neowin servers, take away most chances of your password being stolen.

Edited September 9, 2004 by The_Decryptor

[Glowstick]

i think that is a nice idea Tom - i'd think it might be better managed through IVB - have you tried / proposed it there?

I doubt they'll be implementing this on short term. They also want me and my pal to pay a hundred bucks for a forum license to access all features, so I prefer if they get that idea by themselves.

If it's about pushing the maintainer duties off to someone else, a potential SOAP service would be a piggyback thing anyway, since you basically just need access to the database, theor. no hacks whatsoever on the IPB code.

[john smith 1924 Veteran]

No - i wasn't trying to offload it tom; i merely wondered if this is quite a big feature that perhaps would be better deployed IVB sites wide.

[+chorpeac MVC]

I also like the idea of a web based login hosted on the neowin servers, take away most chances of your password being stolen.

Well this is already done, so we are half way there!

[Glowstick]

No - i wasn't trying to offload it tom; i merely wondered if this is quite a big feature that perhaps would be better deployed IVB sites wide.

Big? Don't know. Timdorr makes it sound like PHP has support for the SOAP protocol, so it shouldn't be that hard. Most jobs would be just wrapping SQL query results into XML and sending it to the client application. The auth thing itself I wrote above is rather simple IMO.

[The_Decryptor Veteran]

I had an idea about preventing bad people from exploiting the service

Here's the idea, instead of letting just anybody access the possible webservices, they have to apply for a "Neowin ID" or something like that (by going to www.neowin.net/developer or something), the id would be linked to their specific account and must be sent along with all soap requests, so you can track what programs are doing what, so if a program is suspected of spamming the site, it can be tracked to who wrote it.

I got the idea from the Amazon and Google web services, where the user has to be a registered user and have a id to access the services.

Also, i think the timeout should be extended from 10 minutes to something else, or be able to apply for a longer timeout, because i don't think users would like to re-authenticate every 5-10 mins using a program the access's neowin.

[+chorpeac MVC]

Well the timeout works well for the current login tool....because you only have 60 seconds to restablish contact with Neowin to authenticate the ticket. However, if you guys are looking for a ticket system that works with a web service, that can be continually hit by external apps....does it even make sense to have a timeout??

I mean, you have to get a ticket to authenticate, but then after that, all that unnecessary traffic for reauthentication again and again would bog.... :huh:

Unless what you are talking about is the ticket would expire after x time period of inactivity, and then you have to reauthenicate....so that way a continuous communication between whatever application and Neowin will be good to go.

[Glowstick]

However, if you guys are looking for a ticket system that works with a web service, that can be continually hit by external apps....does it even make sense to have a timeout??

Yes, however should the timeout be several minutes.

Lets say the timeout is 10 minutes, calling a SOAP job within that timespan would reset the timeout counter on the server, since the server knows the application is active, however if the time between the previous and current job is more than 10 minutes, the server should respond with an expired ticket error. To prevent this however, there should be a simple NOOP job with the only purpose of refreshing the ticket. A client side library would track and handle the ticket refreshing independently (timer thread or whatever).

The timeout period shouldn't be too short, otherwise applications might ream the server, which isn't exactly wanted. Also, if someone creates a client side library, it should share a single session. In .NET you could do this via remoting, native code via RPC.

[+chorpeac MVC]

Lets say the timeout is 10 minutes, calling a SOAP job within that timespan would reset the timeout counter on the server, since the server knows the application is active, however if the time between the previous and current job is more than 10 minutes, the server should respond with an expired ticket error. To prevent this however, there should be a simple NOOP job with the only purpose of refreshing the ticket. A client side library would track and handle the ticket refreshing independently (timer thread or whatever).

yeah this is what I was thinking, just long enough so that the ticket stays active for normal use.

[Tim Dorr Veteran]

Timdorr makes it sound like PHP has support for the SOAP protocol, so it shouldn't be that hard.

Well, that *is* how my sig gets it's information ;)

Here's the idea, instead of letting just anybody access the possible webservices, they have to apply for a "Neowin ID" or something like that (by going to www.neowin.net/developer or something), the id would be linked to their specific account and must be sent along with all soap requests, so you can track what programs are doing what, so if a program is suspected of spamming the site, it can be tracked to who wrote it.

I've actually thought of something like that, but due to it's complexity, I've wondered: is it really worthwhile to implement? Honestly, I don't think so. I mean, someone can just find the ID of an existing app and piggyback off that. So, it doesn't really offer any level of security and just adds to the complexity of the project.

Lets say the timeout is 10 minutes, calling a SOAP job within that timespan would reset the timeout counter on the server, since the server knows the application is active, however if the time between the previous and current job is more than 10 minutes, the server should respond with an expired ticket error. To prevent this however, there should be a simple NOOP job with the only purpose of refreshing the ticket. A client side library would track and handle the ticket refreshing independently (timer thread or whatever).

Exactly what I was thinking as well.

What I think should be formed now is a list of functions to flesh out the full API to be made available. There's some data we can't provide, but I'm sure there's a lot people could make use of.

[The_Decryptor Veteran]

I've actually thought of something like that, but due to it's complexity, I've wondered: is it really worthwhile to implement? Honestly, I don't think so. I mean, someone can just find the ID of an existing app and piggyback off that. So, it doesn't really offer any level of security and just adds to the complexity of the project.

You've got a point there.

[+chorpeac MVC]

well there, Mr. puking avatar, Timdorr,.. :) .... can you give us an idea of what we would not be able to access?

[Tim Dorr Veteran]

I dunno. I'd have to run it by the admins. I can code it to do pretty much anything, it's just how they want to handle it.

[Glowstick]

I can't think of any functions except stuff like Top 10 posts of a specific forum (with respective forum enumeration function) and PMs. Other people should post suggestions.