I need to know a couple of things, concerning IRC servers that I couldnt directly find out over google (or werent clear enough for me to be sure if it actually works)
I'm working at a larger community site, and wanted to deliver an in-page chat. Since it would be a nice feature to let people access it from outside too, over their own clients, I tought implementing an IRC Server would be the best solution (probably dedicated, I'll have to teach myself a couple of things for that)
I plan to include a Web-based IRC client over an APE Client / Server. The problem is, I want to strip down the user rights, to disallow many functionalities that IRC would offer:
Change of nicknames: The user logs in over the Page login, and I'll automatically create an IRC auth for this user with that password. So basically, he would connect to the IRC client over a button. And after connecting, he shouldnt be able to change his nickname at all
Creating channels: I want the possibility to create channels, but not from 'normal' users. Basically, I would prefer to set up basic channels that are public, and if a user really creates an own channel, that one should be private and via invitation (is that possible?)
Private conversations: private conversations should be filtered out from the allaround IRC client, into separate 'in-browser-windows' that I create over JS. I guess I just have to filter the stuff coming from IRC - or is there a better solution to that?
Only 'registered' users have access: Like I said, if someone registers on the page, I would like to create an IRC 'account' for him. Users that arent registered on the page, cant access the IRC server at all (or get thrown out). Mainly to avoid spammers or bots from outside.
Is this stuff solvable over IRC? I've read some FAQ's and Instructions for IRC OP's and servers, but I couldnt find a clear answer - it seems that everyone can do pretty much everything - I would like to configure it in a way that user possibilities are more cut down. Basically, giving users the possibility to chat, but not more.
So the Question basically is, how possible / solvable this issues are allaround, or if I have to find other solutions for this.
Have a look at different IRC services, example, ChanServ. Use Channel and User modes to set specific flags.
You can most likely do the following server side:
Forced nicknames (NickServ)
Allow only certain user types to create channels
Allow any user to join channel once it is created
Channels can have invite only flag +i
Private conversations is just a private message to a different user. If you need private conversations to have more than one user, you'll need to implement some logic for using channels privately
Creating registered users should be possible, and can probably be enforced by an IRC service like NickServ for instance.
Consider using CGI:IRC. It's a chat client in the browser which connects to IRC through the webserver. You can either restrict what the user is allowed to do from there, or restrict it server side.
Do some research on different IRCd's and see if you find one that supports what you need. Dancer-IRCd seems a popular choice and is included in the Ubuntu apt-get repository, however I'm not sure it supports all your needed functionality.
Another option is dropping the whole idea of IRC all together and implement your own chat client using either WebSocket API or Comet. There are also complete solutions for this available.
Examples of this:
Comet: CometChat
Websocket API: Websocket Chat Demo
Related
I'm fairly new to programming and I'm studying App development with Ionic and using Laravel as a backend. So far I have created a simple system with sign up and login of users and creation of "events" by the users. I have made the relation between the users and events as the app will need to know which user created an event, and the participants of such event.
Now, I was wondering about adding a messaging system between users and obviously push notifications and stuff and came across Firebase. I've read about it before, but haven't really used it so I'm not quite familiar with it.
My question is, is it possible or even recommended that I use both MySQL and Firebase in my app or should I just stick to one? I've read about Websockets if I stick with Laravel, but on the other hand, Firebase also handles user login and registration in case I want to move to Firebase completely. I'm having some technical questions, such as:
if I'm using both MySQL and Firebase in my app, how would I connect the user that was registered with an ID and a username stored in my MySQL to Firebase, which will need to know which user has sent a message to another one? Can that be done, or recommended?
Should I just stick with just one for my use case (MySQL or Firebase, instead of both)?
I have researched about use cases similar to mine and couldn't find anything, if you guys have come across such situation, could you recommend any materials? It would be much appreciated!
Thanks a lot everyone! I hope my questions were clear, if you need more details, please let me know!
If you decide to use Firebase, it comes with a built-in authentication system so you wouldn't need a MySQL database or your own server.
If you decide to use both anyways (if you have a good reason to do so), you would have to handle all the logic for copying the authenticated user id over to firebase (and validating access) on your own server. If you don't need to do that just keep it simple: Firebase or your own server + MySQL.
So I have the website that provides the API for logging in/registering/etc. And I have the MediaWiki set up at my server.
I need to disallow MediaWiki registration and only allow logging people in through our API. So, when the user tries to login, no request to MediaWiki db for the user should be done, instead the request to our API should be done, logging person in if our API returned the correct data and displaying an error if it didn't.
Is there a way to get it done with MediaWiki?
Thanks in advance.
Your question is very broad and involves some development but also a lot of configuration as well. So, let's start:
First of all, you need to somehow integrate with the API you mentioned, which is possible by developing your own primary authentication provider. See the high level documentation. In this, you will have all the necessary entry points a user might hit when logging in or registering a new account and you can "translate" them to the actual actions which you need to do in your API (which you do not mention what it is or provides, so we can not give you better guidance here).
The second step would then be to configure this new authentication provider as the only one using $wgAuthManagerConfig which will in fact disable all other ways of creating other accounts as well as logging in with other accounts then the ones provided from your API.
If you've more questions, I would suggest that you provide more information and specific points where you're stuck :)
You can have a look at Extension:Auth remoteuser, it could fit at least partly you needs.
I have the gist of how to connect to a MySQL server, however my dilemma is using passwords. Here are some of the things I am looking at.
Architecture will be 1 core service which as of right now will be set up as a digest authentication service. Note: In the future I will also have it set up for kerberos authentication.
The service will have a schema it will need to be able to access in MySQL. Also the micro services will have their own schemas that they will also need to be able to access.
The database will be localhost initially but will eventually be moved (in production) to a separate server altogether.
Given the requirements above, I cannot give the services users that are restricted to localhost and have no password associated with them (nor would I want that in the event the server was hacked). So how can I have access to the database without using any plain text passwords (I don't want it stored in the code)?
Maybe I am just not understanding something here that could make my life so much easier so again I look towards the wisdom of the many here. Thanks in advance!
Some things that I should maybe mention: I plan on using go-martini as my http router, I'd like to be able to set up OAuth Provider, I will need to manage user sessions and authentication (right now not as important as I'm trying to get the core part of the service setup)
Edit: To clarify some information;
I do not have an AD, kerberos, or any other LDAP service to use and would be hard pressed to set them up at this time in a VM I use for development.
The service should not be dependent on any of those items as SSO is a much later requirement in this project.
Strictly speaking it will be deployed in environments where there are none of those available and this is non-negotiable.
I also am specifically developing the services in Go and the clients in React.
Note: I do not need someone to correct MY question. I would appreciate it if you do not change the context of my question to suite the answer you wish to give me. That is not what StackOverflow is about, it is also quite rude to do that. Thank you.
Here is what I'm doing. I will have an online game that is a real exe application that clients run. Clients connect to my game server. They will have stats, achievements, and be able to buy various things for which I will use PayPal IPN service.
When a player wants to log on, I must be able to retrieve their profile and information from somewhere. When a player wins a game, the game server must be able to add a point to their profile.
Users will need to be able to access their stats from the Web Site, or from the game itself.
Would it be a good idea to use the MySQL database that comes with the Web Site for everything. In that, the game server would get and set properties through php or something?
Otherwise what might be a better solution? Is there a way for my web site to use a database that is on the game server machine, if so would that be a good idea?
How is this sort of problem usually solved?
Thanks
Where you put the database doesn't really matter. If you already have one and it can handle the load, use it. But for security and general organization, you should create a separate database and user within MySQL for your game score information. The user should only be able to access the game data database. This way your other data in the data base is protected from your web interface to the game data in case of a PHP or SQL vulnerability.
MySQL is defineatly the way to go. I have a current setup in a folder outside of public html called users, when a user registers a subfolder inside users is created along with a mysql entry. I use MySQL for username/pass/DOB/etc. and the user's folder for storing pics, acheivements in XML, and comments.
As for the client, I'm sure you could initialize a invisible web browser to access the page, and then use simple coding to get data from the web browser.
MySQL is a popular choice for persistence. Load up the profile at login and cache the data on the client. Then write the updates back at the end of the session. This is one of the things MySQL/PHP was made for. It is cheap, easy and performs and scales well.
Backstory
I work for a company that has an online site that allows user to text personal information for collection. We collect the data, and make it available online. Users can choose to share the data with other users.
Going Forward
At some point, this may become classified an FDA-governed medical tool. In anticipation, we'd like to have in place a logging system that shows each time someone accesses our users' data, whether it be the user themselves, another authorized user, or a support person.
Current Architecture
We are currently running Ruby/Rails, and using a MySQL database. The personal information is encrypted in the database.
Data Access for Support
Today, support personnel can access data one of three ways:
admin site The admin site is limited to whatever screens we develop. While we don't currently, we could easily add logging to keep an audit trail of who accessed which data using the admin tool.
sql client I use MySQLWorkbench to access production. However, when connected this way, all personal information (user name, cell number, etc), is encrypted.
Ruby Rails console - Finally, support can log into one of the production boxes and use the Ruby/Rails console from command line. Ruby will decrypt the data, so we can do some simple things such as
u=User.find_all_by_state('active')
and it will return the recordset of all users with state='active', and decrypt their personal information in the resultset.
Holy Grail
logging
easy access for support
I'd love to be have a way to allow easy support access (once authenticated) to the data, but would log everything that is accessed (read or updated). That way, if I'm checking out my buddy's ex-wife's data for example, it gets logged to a place where I can't get in and clean it the audit trail. (See Google firing Gmail employee for an example of employees breaching the data policies).
Anyone have ideas, thoughts, experiences, suggestions with this issue?
hey devguy. This was a issue for me a couple months back. We ended up centralizing our mysql queires so that we could start to track all information coming in and out. Unfortunately the class I wrote is in PHP but the idea behind it could make it very easy to start logging.
https://code.google.com/p/php-centralized-mysql-controller/
Try stored procedures. Make all code use the stored procedures for CRUD activities. This defines an API that your developers can use while business rules are global enforced (don't return entire SSN values, but only last 4 digits, etc).
This serves as the basis for an external API as well.
If you want logging/auditing, you put it in the procedure.
This protects you from everyone except the DBAs.