These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

EVE Technology Lab

 
  • Topic is locked indefinitely.
 

TEA (v1.3.1) - Member Management Mod for SMF 2, TeamSpeak 3 and Jabber
Author
Previous Topic Next Topic
a newbie
Kenbishi Heavy Industries Inc.
#281 - 2014-05-19 03:28:21 UTC  |  Edited by: a newbie
*pods self*

disregard, newb mistake XD

...um.. fire?
Tahnil
Gunboat Commando
#282 - 2014-05-19 08:28:22 UTC  |  Edited by: Tahnil
Tahnil wrote:
Shin Chogan wrote:
Tahnil wrote:
Hi. How should I proceed if I wanted to enable Jabber by default?

Currently every member of my SMF forum has to enable his openfire account manually in his profile. But I want to force usage of Jabber, and therefore I want activation by default.

Any ideas?



As is no can do ... the system needs you to provide a password to the User Service in order to create the account and since the hashing is one way it can't just provide the one you use in the forums.


I don‘t know if this is the case, but if the storage mechanism / encryption method of SMF and openfire were the same, wouldn‘t it be possible to copy the hashed password to the openfire database table?

Quote:
It would need an extra field in the registration process and you'd have to not allow registrations without API Keys.


That would be no problem in our case, as this is already the case.


By the way, I solved this issue on my own. In case anybody is interested…

It is NOT possible to use the hashed SMF password in openfire. Because openfire doesn‘t use hashed passwords. It uses Blowfish encryption with a (not so) secret key, that is stored in the database.

Of course this is a security nightmare. If you have the key (which can simply be obtained from the opfenfire DB) you can decrypt all passwords that are stored in the openfire database.

@Shin Chogan: Maybe you should add a corresponding hint text to the Jabber screen in SMF.

Activation of Jabber accounts by default should still be possible, though. The correct way to do this would be to generate a password for the SMF user and display it in his profile. That would mitigate obove mentioned security problem at the same time, as it prevents people from using a „real“ password (which might be used in other, more critical contexts as well).
Shin Chogan
Federal Navy Academy
Gallente Federation
#283 - 2014-05-19 20:47:26 UTC
Tahnil wrote:


Activation of Jabber accounts by default should still be possible, though. The correct way to do this would be to generate a password for the SMF user and display it in his profile.


That certainly sounds like one way to approach it. Though you then have to store the generated password in the SMF db in some kind of reversible hash (or plain text) ... sounds like you are moving the problem from one DB to the other Big smile

Quote:

That would mitigate obove mentioned security problem at the same time, as it prevents people from using a „real“ password (which might be used in other, more critical contexts as well).


Seriously ??? in this day and age what kind of numpty uses the same password for more than one account. Shocked
Tahnil
Gunboat Commando
#284 - 2014-05-19 21:49:56 UTC  |  Edited by: Tahnil
Shin Chogan wrote:
Tahnil wrote:


Activation of Jabber accounts by default should still be possible, though. The correct way to do this would be to generate a password for the SMF user and display it in his profile.


That certainly sounds like one way to approach it. Though you then have to store the generated password in the SMF db in some kind of reversible hash (or plain text) ... sounds like you are moving the problem from one DB to the other Big smile


No. My suggestion is to use a randomly generated password for the Jabber account. This password will be not secure at all, as it will be stored in the openfire database. As it is a random password, and as the SMF user won‘t be able to change it, it will never be identical with the REAL (SMF) password of the user. Thereby we are creating a second sphere of less (or NO) security, without compromising the real password of the user.

Of course there should be a hint text explaining, that this Jabber password is just a token and therefore not a password in a strict sense (we should avoid to produce the false assumption of a safe Jabber password, as it‘s inherently unsafe).

Quote:

That would mitigate obove mentioned security problem at the same time, as it prevents people from using a „real“ password (which might be used in other, more critical contexts as well).


Shin Chogan wrote:
Seriously ??? in this day and age what kind of numpty uses the same password for more than one account. Shocked


I think you can‘t tell this for every user for sure. I for myself for example do have tiers of password security, and so I might have the same password for several web applications of a specific „tier of importance“. Online banking for example is in the highest tier of security, some stupid EVE application on the other hand might be in the lowest tier of importance. Etc.

But we really don‘t have to argue about that. As web developers we should always think from the user‘s perspective. There will be users who have trust in the security of the architecture of any web application (and yes, that is naiive thinking, nevertheless it happens for sure). We have to protect users as good as possible.

Therefore I would say that the mechanism in TEA should be changed.
Temar Radeik
Aliastra
Gallente Federation
#285 - 2014-05-20 08:38:37 UTC
im back Big smile
Tahnil
Gunboat Commando
#286 - 2014-05-20 09:15:52 UTC
Say whaaaat? Big smile
Shin Chogan
Federal Navy Academy
Gallente Federation
#287 - 2014-05-20 11:22:02 UTC  |  Edited by: Shin Chogan
Tahnil wrote:

No. My suggestion is to use a randomly generated password for the Jabber account. This password will be not secure at all, as it will be stored in the openfire database. As it is a random password, and as the SMF user won‘t be able to change it, it will never be identical with the REAL (SMF) password of the user. Thereby we are creating a second sphere of less (or NO) security, without compromising the real password of the user.



so the users still have to go to their profile to find out what their randomly generated password is ? so you've gained what exactly ? The user has saved possibly a few mouse clicks and typing 10 or so characters. The users still need to log into Jabber, if they didn't want to do that then automatically creating the account isn't going to increase your jabber uptake Smile

Quote:

Of course there should be a hint text explaining, that this Jabber password is just a token and therefore not a password in a strict sense (we should avoid to produce the false assumption of a safe Jabber password, as it‘s inherently unsafe).


I've not looked at the Openfire password encryption so can't comment but surely it is better than having a token that is fixed and can't be changed ? Though I can see what you are saying if you assume that people are reusing critical passwords. I'm kinda 50/50 on that aspect ... Darwinism is kinda harsh at times but how else do you make the species stronger ?

Edit ... ok looked and yes decrypting the passwords is really really trivial Roll

You are also assuming someone has access to your Openfire DB other than yourself ... are you saying you can't be trusted ? ... Are you running the password decryption on your Openfire DB and trying it against accounts on other services ... you can go to jail for that Lol

I'd actually say a "better" way to fix this would be to use LDAP for openfire auth, write an SMF ldap authenticator (I've only found one that works with v 2 on some Russian site and I've not tested it or confirmed its security Blink), Scrap the Temar's plugin to SMF as it is now and make it modify the LDAP directory directly.
Shin Chogan
Federal Navy Academy
Gallente Federation
#288 - 2014-05-20 11:30:13 UTC
Temar Radeik wrote:
im back Big smile


welcome back
Tahnil
Gunboat Commando
#289 - 2014-05-20 11:51:53 UTC
Shin Chogan wrote:
Tahnil wrote:

No. My suggestion is to use a randomly generated password for the Jabber account. This password will be not secure at all, as it will be stored in the openfire database. As it is a random password, and as the SMF user won‘t be able to change it, it will never be identical with the REAL (SMF) password of the user. Thereby we are creating a second sphere of less (or NO) security, without compromising the real password of the user.



so the users still have to go to their profile to find out what their randomly generated password is ? so you've gained what exactly ? The user has saved possibly a few mouse clicks and typing 10 or so characters. The users still need to log into Jabber, if they didn't want to do that then automatically creating the account isn't going to increase your jabber uptake Smile


Right now I have installed converse.js in my SMF. This is a Javascript XMPP Client. Everybody who logs into our forum AND has at some time in the past activated his Jabber account is automatically connected to the Jabber server and can send and receive Jabber messages while surfing on any page of our forum. The connection is established silently in the background, so no user interaction is needed at all.

All users who don‘t want to install a separate Jabber client don‘t need the Jabber password ever. All other users will have to copy and paste their Jabber password (or token) into their respective Jabber application (Pidgin, or whatever).

Shin Chogan wrote:
Quote:

Of course there should be a hint text explaining, that this Jabber password is just a token and therefore not a password in a strict sense (we should avoid to produce the false assumption of a safe Jabber password, as it‘s inherently unsafe).


I've not looked at the Openfire password encryption so can't comment but surely it is better than having a token that is fixed and can't be changed ? Though I can see what you are saying if you assume that people are reusing critical passwords. I'm kinda 50/50 on that aspect ... Darwinism is kinda harsh at times but how else do you make the species stronger ?

Edit ... ok looked and yes decrypting the passwords is really really trivial Roll

You are also assuming someone has access to your Openfire DB other than yourself ... are you saying you can't be trusted ? ... Are you running the password decryption on your Openfire DB and trying it against accounts on other services ... you can go to jail for that Lol

I'd actually say a "better" way to fix this would be to use LDAP for openfire auth, write an SMF ldap authenticator (I've only found one that works with v 2 on some Russian site and I've not tested it or confirmed its security Blink), Scrap the Temar's plugin to SMF as it is now and make it modify the LDAP directory directly.


The thing is that the current implementation of TEA with Jabber is a (potential) breach of security. This is independent of whatever I‘m saying or doing. Of course there may be better solutions than TEA with Jabber, but what speaks against making TEA better and more secure?
Shin Chogan
Federal Navy Academy
Gallente Federation
#290 - 2014-05-20 12:50:32 UTC
Tahnil wrote:

Right now I have installed converse.js in my SMF. This is a Javascript XMPP Client. Everybody who logs into our forum AND has at some time in the past activated his Jabber account is automatically connected to the Jabber server and can send and receive Jabber messages while surfing on any page of our forum. The connection is established silently in the background, so no user interaction is needed at all.

All users who don‘t want to install a separate Jabber client don‘t need the Jabber password ever. All other users will have to copy and paste their Jabber password (or token) into their respective Jabber application (Pidgin, or whatever).


ah so you have a specific use case that you are trying to accommodate. Blink

Quote:


The thing is that the current implementation of TEA with Jabber is a (potential) breach of security. This is independent of whatever I‘m saying or doing. Of course there may be better solutions than TEA with Jabber, but what speaks against making TEA better and more secure?


The breaches in security are Openfire and the users themselves. If you want to develop a solution that works for your use case and what you see as a security flaw then go ahead the code is there however at this time it isn't something I'm looking to add. There are better solutions which would fix other problems some of which may be considered even more of a security issue.

As a case in point you might want to look at how the user service plugin works ... you'll be running screaming from the treetops Blink
Tahnil
Gunboat Commando
#291 - 2014-05-20 14:23:53 UTC  |  Edited by: Tahnil
In fact I already recommended that you at least add a warning to the Jabber screen, where users enter a password. That shouldn‘t be too much of an effort, and the minimal fix for the security issue.

Of course all of my suggestions are rooted in my experience with the mod and what I see as shortcomings. Therefore I have specific use cases. I think that‘s not bad at all.

So to sum up I have two suggestions:

a) Close a potential security hole by substituting the password functionality with a pre-generated token functionality
b) Add an option to activate all Jabber accounts by default, which is simple in conjunction with a) as users will no longer have to manually provide a password

The result would be a more secure TEA plus new options of integration into existing IT infrastructure.

@user service plugin: I think I will have a look at it at some time in the future.
a newbie
Kenbishi Heavy Industries Inc.
#292 - 2014-05-21 02:48:36 UTC  |  Edited by: a newbie
So I am running into a few things here that I vaguely remember reading about but not in exact context. I managed to connect to my server for about 20 minutes then it started kicking me out and refusing connection. As I looked at the logs, I saw the information linked below. Now this threw me as I was connected and online, so why would it work for 20 minutes and then not?

I am hoping it is a configuration issue that I can fix easily.

Long log spammed with SQL and SSH errors.
SQL/SSL Error Logs
Openfire.conf
Openfire Security Settings - Admin Console

The Server Settings on Openfire Admin Console are set to Enable External Components and share the Secret Key here and on the Jabber settings page in Temars. The certs are set as self signed that do not expire for 5 years, and clients are required SSL with self signed allowed.

Is there anything else I can provide? I noticed I did not see a list of Openfire Console settings ever posted that should be set, I feel like a tutorial needs to be created for this.

*edit:

Also the Openfire Console - Database Properties has seemingly properly populated from the openfire.conf file, however I also get this error:

Quote:
Caused by: java.sql.SQLException: ConnectionManager.getConnection() failed to obtain a connection after 11 retries. The exception from the last attempt is as follows: java.sql.SQLException: Access denied for user ''@'localhost' (using password: NO)


Warning:

Quote:
2014.05.20 02:09:58 org.jivesoftware.database.DbConnectionManager - Failed to create the connection provider specified by connectionProvider.className. Using the default pool.


Info:
Quote:
2014.05.20 23:01:26 org.jivesoftware.openfire.nio.ConnectionHandler - ConnectionHandler reports IOException for session: (SOCKET, R: /98.110.196.10:1024, L: /192.168.1.50:5223, S: 0.0.0.0/0.0.0.0:5223)
javax.net.ssl.SSLHandshakeException: SSL handshake failed.
at org.apache.mina.filter.SSLFilter.messageReceived(SSLFilter.java:416)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilterChain.java:53)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:648)
at org.apache.mina.common.support.AbstractIoFilterChain$HeadFilter.messageReceived(AbstractIoFilterChain.java:499)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.fireMessageReceived(AbstractIoFilterChain.java:293)
at org.apache.mina.transport.socket.nio.SocketIoProcessor.read(SocketIoProcessor.java:228)
at org.apache.mina.transport.socket.nio.SocketIoProcessor.process(SocketIoProcessor.java:198)
at org.apache.mina.transport.socket.nio.SocketIoProcessor.access$400(SocketIoProcessor.java:45)
at org.apache.mina.transport.socket.nio.SocketIoProcessor$Worker.run(SocketIoProcessor.java:485)
at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
Caused by: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
at sun.security.ssl.EngineInputRecord.bytesInCompletePacket(EngineInputRecord.java:171)
at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:848)
at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:761)
at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
at org.apache.mina.filter.support.SSLHandler.unwrap0(SSLHandler.java:668)
at org.apache.mina.filter.support.SSLHandler.unwrapHandshake(SSLHandler.java:624)
at org.apache.mina.filter.support.SSLHandler.handshake(SSLHandler.java:503)
at org.apache.mina.filter.support.SSLHandler.messageReceived(SSLHandler.java:306)
at org.apache.mina.filter.SSLFilter.messageReceived(SSLFilter.java:392)
... 14 more

...um.. fire?
a newbie
Kenbishi Heavy Industries Inc.
#293 - 2014-05-21 03:11:35 UTC  |  Edited by: a newbie
Debug:
Quote:

bytesConsumed = 0 bytesProduced = 0
2014.05.20 23:08:44 org.apache.mina.filter.executor.ExecutorFilter - Launching thread for /98.110.196.10:1024
2014.05.20 23:08:44 org.apache.mina.filter.executor.ExecutorFilter - Exiting since queue is empty for /98.110.196.10:1024
2014.05.20 23:08:44 org.jivesoftware.openfire.nio.ClientConnectionHandler - [/98.110.196.10:1024] Data Read: org.apache.mina.filter.support.SSLHandler@653bb2c2 (HeapBuffer[pos=0 lim=22 cap=1024: 3C 3F 78 6D 6C 20 76 65 72 73 69 6F 6E 3D 27 31 2E 30 27 20 3F 3E])
2014.05.20 23:08:44 org.jivesoftware.openfire.nio.ClientConnectionHandler - [/98.110.196.10:1024] doHandshake()
2014.05.20 23:08:44 org.jivesoftware.openfire.nio.ClientConnectionHandler - [/98.110.196.10:1024] handshakeStatus=NEED_UNWRAP
2014.05.20 23:08:44 org.jivesoftware.openfire.nio.ClientConnectionHandler - [/98.110.196.10:1024] unwrapHandshake()
2014.05.20 23:08:44 org.jivesoftware.openfire.nio.ClientConnectionHandler - [/98.110.196.10:1024] inNetBuffer: java.nio.DirectByteBuffer[pos=0 lim=22 cap=16921]
2014.05.20 23:08:44 org.jivesoftware.openfire.nio.ClientConnectionHandler - [/98.110.196.10:1024] appBuffer: java.nio.DirectByteBuffer[pos=0 lim=33842 cap=33842]
2014.05.20 23:08:44 org.apache.mina.filter.executor.ExecutorFilter - Launching thread for /98.110.196.10:1024
2014.05.20 23:08:44 org.apache.mina.filter.executor.ExecutorFilter - Exiting since queue is empty for /98.110.196.10:1024
2014.05.20 23:08:44 org.jivesoftware.openfire.nio.ClientConnectionHandler - [/98.110.196.10:1024] Data Read: org.apache.mina.filter.support.SSLHandler@653bb2c2 (HeapBuffer[pos=0 lim=117 cap=1024: 3C 73 74 72 65 61 6D 3A 73 74 72 65 61 6D 20 74 6F 3D 27 63 6C 30 6E 65 62 61 79 2E 63 6F 6D 27 20 78 6D 6C 6E 73 3D 27 6A 61 62 62 65 72 3A 63 6C 69 65 6E 74 27 20 78 6D 6C 6E 73 3A 73 74 72 65 61 6D 3D 27 68 74 74 70 3A 2F 2F 65 74 68 65 72 78 2E 6A 61 62 62 65 72 2E 6F 72 67 2F 73 74 72 65 61 6D 73 27 20 76 65 72 73 69 6F 6E 3D 27 31 2E 30 27 3E])
2014.05.20 23:08:44 org.jivesoftware.openfire.nio.ClientConnectionHandler - [/98.110.196.10:1024] expanded inNetBuffer:java.nio.DirectByteBuffer[pos=0 lim=17155 cap=17155]
2014.05.20 23:08:44 org.jivesoftware.openfire.nio.ClientConnectionHandler - [/98.110.196.10:1024] expanded appBuffer:java.nio.DirectByteBuffer[pos=0 lim=34310 cap=34310]
2014.05.20 23:08:44 org.jivesoftware.openfire.nio.ClientConnectionHandler - [/98.110.196.10:1024] doHandshake()
2014.05.20 23:08:44 org.jivesoftware.openfire.nio.ClientConnectionHandler - [/98.110.196.10:1024] handshakeStatus=NEED_UNWRAP
2014.05.20 23:08:44 org.jivesoftware.openfire.nio.ClientConnectionHandler - [/98.110.196.10:1024] unwrapHandshake()
2014.05.20 23:08:44 org.jivesoftware.openfire.nio.ClientConnectionHandler - [/98.110.196.10:1024] inNetBuffer: java.nio.DirectByteBuffer[pos=0 lim=117 cap=17155]
2014.05.20 23:08:44 org.jivesoftware.openfire.nio.ClientConnectionHandler - [/98.110.196.10:1024] appBuffer: java.nio.DirectByteBuffer[pos=0 lim=34310 cap=34310]
2014.05.20 23:08:44 org.jivesoftware.openfire.nio.ClientConnectionHandler - [/98.110.196.10:1024] Unwrap res:Status = CLOSED HandshakeStatus = NEED_WRAP
bytesConsumed = 0 bytesProduced = 0
2014.05.20 23:08:44 org.jivesoftware.openfire.nio.ClientConnectionHandler - [/98.110.196.10:1024] write outNetBuffer: java.nio.DirectByteBuffer[pos=0 lim=7 cap=16921]
2014.05.20 23:08:44 org.jivesoftware.openfire.nio.ClientConnectionHandler - [/98.110.196.10:1024] session write: HeapBuffer[pos=0 lim=7 cap=7: 15 03 01 00 02 02 50]
2014.05.20 23:08:44 org.jivesoftware.openfire.nio.ClientConnectionHandler - [/98.110.196.10:1024] Unexpected exception from SSLEngine.closeInbound().
javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?
at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1630)
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1598)
at sun.security.ssl.SSLEngineImpl.closeInbound(SSLEngineImpl.java:1528)
at org.apache.mina.filter.support.SSLHandler.destroy(SSLHandler.java:167)
at org.apache.mina.filter.SSLFilter.initiateClosure(SSLFilter.java:559)
at org.apache.mina.filter.SSLFilter.messageReceived(SSLFilter.java:406)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilterChain.java:53)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:648)
at org.apache.mina.common.support.AbstractIoFilterChain$HeadFilter.messageReceived(AbstractIoFilterChain.java:499)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.fireMessageReceived(AbstractIoFilterChain.java:293)
at org.apache.mina.transport.socket.nio.SocketIoProcessor.read(SocketIoProcessor.java:228)
at org.apache.mina.transport.socket.nio.SocketIoProcessor.process(SocketIoProcessor.java:198)
at org.apache.mina.transport.socket.nio.SocketIoProcessor.access$400(SocketIoProcessor.java:45)
at org.apache.mina.transport.socket.nio.SocketIoProcessor$Worker.run(SocketIoProcessor.java:485)
at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
2014.05.20 23:08:44 org.apache.mina.filter.executor.ExecutorFilter - Launching thread for /98.110.196.10:1024
2014.05.20 23:08:44 org.apache.mina.filter.executor.ExecutorFilter - Exiting

...um.. fire?
Jen Moriarty
Out of Focus
Odin's Call
#294 - 2014-05-21 07:28:58 UTC
Got a small question about the TEAC code:

In the TEAC.php file there's a function called standings(). I'm using it to access my corp's blue list. This function calls get_xml() which gets the bluelist's XML file from the EVE API. I'm trying to understand the purpose of $cache there:
Quote:

$cache = FALSE;
if($type != 'calllist' && $type != 'standings' && $type != 'personalstandings' && $type != 'alliances' && method_exists($this, 'get_cache'))
{
$cache = $this -> get_cache($url, $post);
}

if($cache)
$ret_val = $cache;
else {
$ret_val = $this -> get_site($this -> server.$url, $post);
}


So if the $type parameter is standings, this function does not use the cache. Why is that? Does this mean you do not need to cache calls to the /corp/ContactList.xml.aspx API? Call I call ContactList.xml.asp as often as I like?

Thanks!
Shin Chogan
Federal Navy Academy
Gallente Federation
#295 - 2014-05-21 09:06:17 UTC
Quote:

So I am running into a few things here that I vaguely remember reading about but not in exact context. I managed to connect to my server for about 20 minutes then it started kicking me out and refusing connection. As I looked at the logs, I saw the information linked below. Now this threw me as I was connected and online, so why would it work for 20 minutes and then not?


What do you mean "kicking me out and refusing connection" ? are you talking about your jabber client ? If so you are asking in the wrong place you need to talk to the openfire guys.
Shin Chogan
Federal Navy Academy
Gallente Federation
#296 - 2014-05-21 09:22:36 UTC
Jen Moriarty wrote:
Got a small question about the TEAC code:

So if the $type parameter is standings, this function does not use the cache. Why is that? Does this mean you do not need to cache calls to the /corp/ContactList.xml.aspx API? Call I call ContactList.xml.asp as often as I like?

Thanks!


No the get_xml function doesn't cache the result coz the code that calls it in TEA.php does the "caching"

The ContactList.xml.asp is the long cache style so it is like Market transactions ... once you fetch it you wont get anything at all from CCP until the cache timer has expired on their end.

when the get_xml is called in TEA.php to get the contact list it actually parses the xml and stores the data it in a file, at the beginning of the file is the timestamp of when it was created and it wont actually get the contact list again for for 24 hours.

Quote:

if($time > (time() - (60 * 60 * 24)))


if you want it more frequent you can change that but since I've yet to get round to putting in proper cache timers based on the cache until value in the xml you'll need to make sure that you look at some raw XML to work out the minimum acceptable time. I did look at one point but I can't remember what the value was.
Shin Chogan
Federal Navy Academy
Gallente Federation
#297 - 2014-05-22 12:12:54 UTC
R6 released.

r6 change notes

  • Misc Changes to error handling. Error 221 is treated as transient and will be rechecked (Note this error will be cached for 1hr).
  • Added option to restrict access for a group ... people in this group will only have Corp rules processed - designed for Alliance boards to allow them to remove access to a corp before the corp has been dropped from the Alliance but allows the possibility of controlling access via corp name.
  • Added option to prevent a specified group from having an account at all on Jabber even if other rules say they should.
  • Clean up scheduled tasks on uninstall of MOD
  • Now should remove all groups from forum accounts with only toons that exist on other forum accounts.
  • Warning about Openfire Password insecurity.
  • Bugfix for API required during Registration.


Tahnil
Gunboat Commando
#298 - 2014-05-22 21:31:20 UTC
Hello.

I updated to r6 and now I can‘t switch my preferred character anymore. Any ideas?
Shin Chogan
Federal Navy Academy
Gallente Federation
#299 - 2014-05-23 08:41:52 UTC
Tahnil wrote:
Hello.

I updated to r6 and now I can‘t switch my preferred character anymore. Any ideas?



Wuppps ... Regression test fail ... I have some customizations in for our board and I forgot to revert one of the bits back to the normal code for release.

New version posted.
Ariesss
Alfa Corporation
Fanatic Legion.
#300 - 2014-05-29 22:21:29 UTC

Hi guys!

How to fix this error ?

index.php?action=admin;area=tea;sa=settings;a5e37876e7=25057d1a04baf8e9d614b14bae7d37ff

8: Undefined variable: reds

www/Sources/TEA.php
row: 253