Pages: 1 2 3 4 5 6 7 8 9 [10] 11 12 13 14 15 16 .. 16 :: one page |
|
Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Yveth
Sons of Ivaldi Zero Hour Alliance
1
|
Posted - 2014.04.13 15:55:00 -
[271] - Quote
Is there already a fix known for people that have to register with API? (for a new account) Or did i miss that post?
Thank you |
Shin Chogan
Blueprint Haus Get Off My Lawn
57
|
Posted - 2014.04.14 08:25:00 -
[272] - Quote
Yveth wrote:Is there already a fix known for people that have to register with API? (for a new account) Or did i miss that post?
Thank you
I guess it depends on what is broken about it that you want a fix for |
Yveth
Sons of Ivaldi Zero Hour Alliance
1
|
Posted - 2014.04.14 14:34:00 -
[273] - Quote
People should register with api before the account could be activated. Mandatory API key for registering.
Same like: - Account name - Password - Mail |
Shin Chogan
Blueprint Haus Get Off My Lawn
57
|
Posted - 2014.04.14 15:06:00 -
[274] - Quote
Yveth wrote:People should register with api before the account could be activated. Mandatory API key for registering.
Same like: - Account name - Password - Mail
Yeah the fix for that is somewhere in this thread :) |
Tahnil
Sirius Fleet
44
|
Posted - 2014.05.06 10:30:00 -
[275] - Quote
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? |
Shin Chogan
Blueprint Haus Get Off My Lawn
58
|
Posted - 2014.05.07 11:43:00 -
[276] - Quote
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.
It would need an extra field in the registration process and you'd have to not allow registrations without API Keys. |
Tahnil
Sirius Fleet
44
|
Posted - 2014.05.07 15:10:00 -
[277] - Quote
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 donGÇÿt know if this is the case, but if the storage mechanism / encryption method of SMF and openfire were the same, wouldnGÇÿ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. |
Cyph3r Blade
Anarchy-Gaming
0
|
Posted - 2014.05.13 04:38:00 -
[278] - Quote
I've been wroking with rule setups for god knows how many hours, and it's not clicking with me. Can someone who is a guru with rules for TEA who would be willing to assist please mail me? I'm desperate and close to ripping my hair out. |
a newbie
Dissidence Dawn That Escalated Quickly.
46
|
Posted - 2014.05.19 03:28:00 -
[279] - Quote
*pods self*
disregard, newb mistake XD ...um.. fire? |
Tahnil
Sirius Fleet
44
|
Posted - 2014.05.19 08:28:00 -
[280] - Quote
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 donGÇÿt know if this is the case, but if the storage mechanism / encryption method of SMF and openfire were the same, wouldnGÇÿ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 interestedGǪ
It is NOT possible to use the hashed SMF password in openfire. Because openfire doesnGÇÿ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 GÇPrealGÇ£ password (which might be used in other, more critical contexts as well). |
|
Shin Chogan
Blueprint Haus Get Off My Lawn
58
|
Posted - 2014.05.19 20:47:00 -
[281] - Quote
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
Quote: That would mitigate obove mentioned security problem at the same time, as it prevents people from using a GÇPrealGÇ£ 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. |
Tahnil
Sirius Fleet
44
|
Posted - 2014.05.19 21:49:00 -
[282] - Quote
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
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 wonGÇÿ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 itGÇÿs inherently unsafe).
Quote: That would mitigate obove mentioned security problem at the same time, as it prevents people from using a GÇPrealGÇ£ 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.
I think you canGÇÿ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 GÇPtier of importanceGÇ£. 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 donGÇÿt have to argue about that. As web developers we should always think from the userGÇÿ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
Catastrophic Operations The Explicit Alliance
16
|
Posted - 2014.05.20 08:38:00 -
[283] - Quote
im back |
Tahnil
Sirius Fleet
44
|
Posted - 2014.05.20 09:15:00 -
[284] - Quote
Say whaaaat? |
Shin Chogan
Blueprint Haus Get Off My Lawn
58
|
Posted - 2014.05.20 11:22:00 -
[285] - Quote
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 wonGÇÿ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
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 itGÇÿ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 ?
Edit ... ok looked and yes decrypting the passwords is really really trivial
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
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 ), Scrap the Temar's plugin to SMF as it is now and make it modify the LDAP directory directly. |
Shin Chogan
Blueprint Haus Get Off My Lawn
58
|
Posted - 2014.05.20 11:30:00 -
[286] - Quote
Temar Radeik wrote:im back
welcome back |
Tahnil
Sirius Fleet
44
|
Posted - 2014.05.20 11:51:00 -
[287] - Quote
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 wonGÇÿ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
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 donGÇÿt want to install a separate Jabber client donGÇÿ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 itGÇÿ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 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 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 ), 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 IGÇÿ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
Blueprint Haus Get Off My Lawn
58
|
Posted - 2014.05.20 12:50:00 -
[288] - Quote
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 donGÇÿt want to install a separate Jabber client donGÇÿ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.
Quote:
The thing is that the current implementation of TEA with Jabber is a (potential) breach of security. This is independent of whatever IGÇÿ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
|
Tahnil
Sirius Fleet
44
|
Posted - 2014.05.20 14:23:00 -
[289] - Quote
In fact I already recommended that you at least add a warning to the Jabber screen, where users enter a password. That shouldnGÇÿ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 thatGÇÿ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
Dissidence Dawn That Escalated Quickly.
46
|
Posted - 2014.05.21 02:48:00 -
[290] - 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?
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?
...um.. fire? |
|
a newbie
Dissidence Dawn That Escalated Quickly.
46
|
Posted - 2014.05.21 03:11:00 -
[291] - Quote
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
Snuff Box
41
|
Posted - 2014.05.21 07:28:00 -
[292] - Quote
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
Blueprint Haus Get Off My Lawn
58
|
Posted - 2014.05.21 09:06:00 -
[293] - Quote
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
Blueprint Haus Get Off My Lawn
58
|
Posted - 2014.05.21 09:22:00 -
[294] - Quote
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
Blueprint Haus Get Off My Lawn
58
|
Posted - 2014.05.22 12:12:00 -
[295] - Quote
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
Sirius Fleet
44
|
Posted - 2014.05.22 21:31:00 -
[296] - Quote
Hello.
I updated to r6 and now I canGÇÿt switch my preferred character anymore. Any ideas? |
Shin Chogan
Blueprint Haus Get Off My Lawn
59
|
Posted - 2014.05.23 08:41:00 -
[297] - Quote
Tahnil wrote:Hello.
I updated to r6 and now I canGÇÿ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 Dream Fleet
0
|
Posted - 2014.05.29 22:21:00 -
[298] - Quote
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
|
Bill Ramen
Anarchy-Gaming
0
|
Posted - 2014.06.02 19:16:00 -
[299] - Quote
Hi, I'm getting an error when my end users try to register their teamspeak identity of Quote:[ERROR] access to default group is forbidden . It worked initally but I am not sure what has faulted. Can someone assist? |
Nutbolt
Avalon Project Shadow Rock Alliance
89
|
Posted - 2014.06.03 06:49:00 -
[300] - Quote
Right I have had this issue for a while now and getting fed up with it. Basically TEA is caching the results of the API and not clearing the cache. So if I empty the smf_tea_cache table in the DB it will go through and re pull everyones api key and deal with permissions correctly, kicking people who left corp etc... However once its done this once for everyone it then won't refresh their API key again. Meaning permissions aren't being updated should someone leave or whatever.
If someone new joins it gets their info fine (as its not cached in the DB). I have no idea why this is happened, it used to work, like a few months ago now, but did used to work.
The TEA_CRON outputs 'Reset lastid to Zero' Any ideas please?
|
|
|
|
|
Pages: 1 2 3 4 5 6 7 8 9 [10] 11 12 13 14 15 16 .. 16 :: one page |
First page | Previous page | Next page | Last page |