| Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Tahnil
Sirius Fleet
18
   |
Posted - 2013.11.16 12:34:00 -
[1] - Quote
Hello. IGÇÿve got a question. IGÇÿm running TEA with a Jabber connection. I set up everything, but there seems to be a problem. My test character is not activated on the Jabber server. Can anybody tell me how I can see whatGÇÿs going on in the background, whenever I start TEA_Jabber_Cron_Access.php? I canGÇÿt find anything in the openfire logs, even in debug mode. It just seems like thereGÇÿs nothing going on at all.
By the way, the connection seems to work. Most accounts have been transferred to the openfire server, but in at least one case it doesnGÇÿt work, and IGÇÿd like to to some troubleshooting, but I donGÇÿt know how. |
Tahnil
Sirius Fleet
18
|
Posted - 2013.11.16 13:22:00 -
[2] - Quote
Problem solved. Sorry, stupid me.
For anybody who is interested: you can activate a general logfile in mysql where all database access is logged. For this you need to stop mysql service and start it manually with command line options. In Ubuntu this would be something like:
mysqld --general-log --log-output=FILE --general-log-file=/var/log/mysql/general.log
My problem was simply that my test user didnGÇÿt activate his Jabber account in his SMF user profile settings. |
Tahnil
Sirius Fleet
44
|
Posted - 2014.03.15 10:53:00 -
[3] - Quote
Same problem over here! I think CCP changed the API, and Temars API Mod canGÇÿt handle it.
Liez Onerbak wrote:I'm experiencing some issues as of today. If a user tries to register, or an existing user tries to update/add API to profile, or the cron runs (whichever happens first), the characters are coming back without corp tags and therefore not qualifying for any groups. Users are being removed from their groups as well....
For instance, The users are listed in the back end like: [] Your_Name (closed brackets where the corp tag would be)
Any ideas?
* Edit: Been working fine for months and nothing has changed/been updated recently. The only thing that's changed is the new eve patch but I can't imagine that would have anything to do with it...
* Edit #2: Confirmed the same problem happening on another site. Exact same issue. |
Tahnil
Sirius Fleet
44
|
Posted - 2014.03.15 13:58:00 -
[4] - Quote
Shin Chogan wrote:Well if it only started happening Today then it can't be the patch as that was before that :)
What version are you guys running ?
IGÇÿm running v1.3.1r4
If there were no registrations and API checks since patch day, I think it still is possible. I think Demitrios may have identified the issue. DoesnGÇÿt explain though why it works in some versions of the mod, while itGÇÿs broken in others. |
Tahnil
Sirius Fleet
44
|
Posted - 2014.03.18 08:43:00 -
[5] - Quote
How did you manage this? Because I seem to have the same problem. |
Tahnil
Sirius Fleet
44
|
Posted - 2014.05.06 10:30:00 -
[6] - 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? |
Tahnil
Sirius Fleet
44
|
Posted - 2014.05.07 15:10:00 -
[7] - 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. |
Tahnil
Sirius Fleet
44
|
Posted - 2014.05.19 08:28:00 -
[8] - 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). |
Tahnil
Sirius Fleet
44
|
Posted - 2014.05.19 21:49:00 -
[9] - 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. |
Tahnil
Sirius Fleet
44
|
Posted - 2014.05.20 09:15:00 -
[10] - Quote
Say whaaaat? |
Tahnil
Sirius Fleet
44
|
Posted - 2014.05.20 11:51:00 -
[11] - 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? |
Tahnil
Sirius Fleet
44
|
Posted - 2014.05.20 14:23:00 -
[12] - 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. |
Tahnil
Sirius Fleet
44
|
Posted - 2014.05.22 21:31:00 -
[13] - Quote
Hello.
I updated to r6 and now I canGÇÿt switch my preferred character anymore. Any ideas? |
Tahnil
Sirius Fleet
47
|
Posted - 2014.10.07 11:48:00 -
[14] - Quote
Sorry, canGÇÿt help you.
But is Shin Chogan still around? His last postings are several months old :-( |
Tahnil
Sirius Fleet
AXIOS.
52
|
Posted - 2014.11.24 09:21:28 -
[15] - Quote
I could be mistaken, but I think currently there is nobody actively working on the TEA mod :-( |
Tahnil
Sirius Fleet
AXIOS.
52
|
Posted - 2014.11.24 14:27:05 -
[16] - Quote
Temar has quit EVE a long time ago. Shin Chogan took over this project and maintained it for one or two years. But he seems to have quit several months ago. You can have a look at his last postings in this thread.
So anybody who has some experience with PHP, SMF, and the EVE API is invited to take over development ;-)
Unfortunately IGÇÿm just a n00b with regards to web development. |
Tahnil
Sirius Fleet
AXIOS.
57
|
Posted - 2015.01.01 21:19:42 -
[17] - Quote
Do you use a custom theme? I used to have the problem that the plugin wouldnGÇÿt show up in the admin area of a custom theme. If it is correctly installed and activated, it should at least show up in the standard theme. |
Tahnil
Sirius Fleet
AXIOS.
58
|
Posted - 2015.07.07 18:55:35 -
[18] - Quote
What do you expect? ItGÇÿs no longer maintained by any developer. Unless it is. In this case IGÇÿd like to know |
| |
|