For a number of reasons, I do not want to host an actual LDAP server.
Instead, through PHP, I want to simulate the essential functions of an LDAP server.
So I want, for instance, to be able to respond to ldap_search, ldap_connect, ldap_bind, ldap_unbind, etc.
Results would come from MySQL.
It looks like ldap_search would be a matter of returning the same response that an LDAP URL Query would return, which is like a JSON format, but I am unsure about e.g. ldap_bind.
Right now I am just researching the feasibility of providing a "simulated" LDAP Server. I would greatly appreciate any thoughts on how much this would require, using PHP/MySQL.
Thanks in advance!
I think you'll have to go through the protocol specifications and basically build a server implementation. It will give you an idea what you need to do, an LDAP client app will follow the protocol specs very closely.
Specs: https://www.rfc-editor.org/rfc/rfc4510
Related
I apologise if something like this has been answered before, I just can't figure out a good way to word my question well enough to include all details about my problem.
I'd like users to be able to host servers for my indie game in a way virtually identical to, for example, Minecraft. I don't want any official servers, the game is mostly intended to be played with friends and not random strangers.
I've thought of many ways to accomplish this but I could never solve one important detail - I want the server to be able to remember users and put them where they left off when they reconnect (give them their character, the character's inventory, etc).
But any solution I could find or think of either made it potentially very easy to steal someone's character and connect to the server pretending to be them, or required me to make players have a way to register with accounts, something I can't afford to host myself.
I guess what I need is a way for the server to send a token to a new connecting player, and then have a way to see if the player sending that token back is the same person, and not an attempt to replicate the token. That to me sounds like public key cryptography, but the game engine I'm using doesn't seem to have any libraries for that (unsurprisingly), and I certainly am not qualified to make a library like that myself. But maybe there's an easier solution I'm somehow missing.
This might be a stupid question, but I hope it's worth a try asking. Thank you in advance for any help. Sorry I was so wordy by the way.
TLDR: I want users to host game servers that can remember reconnecting players without risk of players' progress being stolen.
If you have not already, look into sessions. Session cookies. But also setting up a basic log in system with php or whatever server code your server uses is not hard, and most basic hosting provide the mysql and php needed to do a basic log in page, you just have to code it yourself.
I've created an api using .net core 2 and C#. I'm wondering if there's anyway to find out information about the computer or user that called the api. This is an internally used api so ideally I'd get the Windows user of where the api call came from, but if there's anything I can find out (like an IP address) I'd like to know how. If this isn't possible at all, I'd like to know so I can stop looking for a solution.
No, it's not possible. The server knows only what the client chooses to tell it, typically via request headers. However, the client can also lie, or "spoof" these headers. So, while something like User-Agent may look like it might give you some info about at least the OS/browser, all of that could be completely fabricated.
Matters are even worse with an API, as clients are typically thin, and the actual programmer or whatever connecting to your API must make a conscious decision to provide you with some particular bit of information, which most won't. A web browser typically sends certain standard things without user intervention, but even then users can change or alter what is sent.
I am trying to get a setup so that I can access Cloudant Couch directly without using a middle tier such as PHP, .NET, or Ruby.
It is possible to avoid the cross-domain problem with script injection or JSONP. One can specify a
But this means that your only method can be a GET.
Does Cloudant have a URL convention or proxy that allows you to specify other methods with a GET?
For example you could DELETE a document with something like:
Thanks in advance. Hoping for responses that are directly applicable, not the "why would you want to do that" kind of response.
You can set up a virtual host on cloudant. I don't think this will help you get around XSS same-origin policy though unless you run your entire application from this virtual host.
Well, they support CORS but not the wildcard syntax. However, that should take care of most of your work. I've posted to their support channels if they support returning JSONP but that does bring us to another work-around: try embeding self executing functions into the data object. I'm betting that the CouchDB folks will prevent it from saving (as we don't want self-executing functions messing with CouchDB's innards) but it's worth a shot.
I'd like use couchdb for a web application with external user authentication by a XMPP-Server (Openfire). How can I achieve that? Let's say we have thre users:
basicuser#mydomain.tld
advanceduser#mydomain.tld
moreadvanceduser#mydomain.tld
Now basicuser#mydomain.tld should be able to read all documents that are suited for basic users.
advanceduser#mydomain.tld should be able to read AND write all documents that are suited for basic users.
moreadvanceduser#mydomain.tld should be able to read all documents that are suited for basic and advanced users.
Is that possible?
following OpenFire's Database installation Guide, only relational Databases work directly with Open Fire:
MySQL
Oracle
Microsoft SQLServer
PostgreSQL
IBM DB2
HSQLDB
My first thought was to try and move the complete database to couchdb.
Anyways, you will need different groups for mapping the different types of users. As far as I know, read/write access in CouchDB cannot be granted or revoked for single documents, but for databases. So you will end up with 3 databases, each for one type of access level.
I am not sure if it is a good advice to hanlde document based authentication in CouchDB by "tagging" documents with authlevels.
So, I can think of different szenarios:
If your XMPP server ot the database
was able to verify credentials via
webservices, you could make use of
that in the login procedure in your
couchapp.
If there are Webservices to your Openfire backing database, you could use these to synchronize users with couchdb and map them to auth lvl groups. I think this is not a very good approach, as you will have to handle updated or deleted users as well and have another point to think about security as well. This could of course also be done by scripting on python or what ever language you prefer.
Use LDAP to provide auth. Does not work with CouchDB for now.
Maybe a good idea would be to make
use of Z-XMPP, strophe or
basically any js framework that
handles XMPP in some way? There you
could learn about XMPP
authentication and maybe use this to
verify auth credentials with XMPP. I also just learned that there is a book about "Professional XMPP Programming with JavaScript and jQuery".
Now, these are no complete solutions provided, but something to think about, and discuss it.
Oh, and there's another Thread here at StackOverflow.
Regards, Chris
I have an app that creates a couple of WebView instances and I'd like to have them operate as independently as possible.
At the very least, I don't want them sharing cookies. A quick google search gave me results liking "you can't." I'm hoping someone has a better answer.
The basic answer is "you can't".
After looking at this for a bit, I think it's possible, but extremely complicated. It would involve implementing a resourceLoadDelegate on your WebView that implements -webView:resource:willSendRequest:redirectResponse:fromDataSource: and modifies the request to turn off HTTPShouldHandleCookies and adds any relevant cookies to the request manually. It also has to implement -webView:resource:didReceiveResponse:fromDataSource: to find out about any cookies returned from the server. You can alloc/init your own copy of NSHTTPCookieStorage per-webview and use that to store/retrieve the cookies.
This post sums up what you could do. I'm not sure if it is feasible for you and I feel it wouldn't be a straightforward task, maybe even risky, but it seems to be possible: the author claims iCab does it this way.
I was hoping for a simpler solution too, really. Of course, since Webkit is open source you could just roll out your own version of the framework with changed behavior I guess?
I would assume that cookies would be configured on a service / application level and not for particular instances or processes. Perhaps you could revise your question to find a way to resolve the problem you are having which requires that the instances do not share cookies.
What is the motivation for not sharing cookies between the instances?
If you just need 3 views into the same web resource you could setup some virtual hosts that point to the same data source.
What you can do is take a look at libcurl which can handle cookie stores that don't mix with the URL Loading system wide cookie storage for those requests you want to separate. For me that seems to be a valid and simple solution. If you really need to depend on webview/webkit it might not be.