Using Solr Basic auth plugin
How do you set permissions based on the "core"? Only want certain users to be able to access a certain core.
I thought that was the "collection" value, but that isn't it.
From my own experience trying to solve this exact issue a year ago - I'm unable to find the reference where I read this, but:
You can't limit access to a specific core through security.json - if you need to limit which users can access which sets of data, you'll have to use SolrCloud and the collections parameter.
You might be able to limit access by having a reverse proxy in front, but be aware that certain GET parameters could be used to switch the request handler back in the "old days" - but that might have been removed now (and not sure if you could switch cores in the same way).
You also have to use the path parameter to limit operations (i.e. to only allow a user to access /select or /replication etc.).
Related
I have been assigned a task to export the AD Attributes than find out what systems are using these attributes. I have not had much luck in scripting or a tool that can provide just that. Is this feasible and if so how? I have already exported attributes. Just need to find what systems are using them.
This isn't possible with any reasonable accuracy, especially if "using" isn't defined for you.
The event logs on the domain controllers will tell you where login events are coming from, but only by IP. That doesn't tell you which application is authenticating. You would have to do monitoring on that computer and see which application is making the connection. But then the logs would be cluttered with connections made by Windows itself, or Exchange (if you use Exchange for email). It it would be very difficult to identify what is coming from an 3rd-party application rather than Windows itself.
Also, applications can request more information than they need. It's very easy when programming with LDAP to request every attribute for an object, even if you only intend to use one. For example, take this C# code:
var de = new DirectoryEntry("LDAP://example.com");
Console.WriteLine(de.Properties["name"].Value);
That only "uses" the name attribute. But because of the way LDAP works, it actually requests every non-constructed attribute that has a value. (there is a way to specifically ask for only one attribute, but you have to know that and use that)
So even if you could find logs saying that "this IP requested all of these attributes", and then figure out which application made that request, that doesn't mean it "used" all of those attributes.
I am currently trying to find out AD users password expiry date.
Using the methods described on numerous pages for e.g. here work fine until a user or group in AD is using a fine grained password policy that does not follow the users domain password policy.
I found a property called msDS-UserPasswordExpiryTimeComputed that figures that all out without trying to do any calculations.
This works well, until we are using a global catalog since this property is not replicated by default. When I attempting to replicate the msDS-UserPasswordExpiryTimeComputed property in my global catalog, I get the following error:
Is there anyway to replicate this property or is something wrong with my setup that is not allowing me to replicate this property? Is there a better way to calculate user password expiry to take into account the fine grained password policy?
I suspect you can't. I can't find any authoritative documentation saying it is not possible, but here are the reasons I think it's not possible:
The attribute is constructed, meaning it's not stored, but it's calculated at the time you ask for it.
The date depends on the policy on the domain, thus the server returning the data needs to know the policy on the domain of the user.
Since a GC may not be on the domain of the user you find, it may not have the information needed to be able to calculate the value.
As a workaround, you can just rebind to a DC to get the value. You didn't say which language you're working with, but usually you can take the path of the object you found, which will start with "GC://", and just replace that with "LDAP://". Then grab the msDS-UserPasswordExpiryTimeComputed value.
I'm working on the front end of an app that uses Solr for data storage. Currently I have an empty index, but it'd (understandably) be a lot easier for me if some dummy data was returned so I could make sure that it's output correctly on the front end.
If I was working with and RDBMS (let's say postgres) I'd open up a GUI (e.g. pgadmin) and type data manually into a few rows to achieve this goal. I have access to the Solr web interface, but I can't see any obvious call to action saying INSERT YOUR DATA HERE. The closest thing I can find to an answer on the web is this SO thread, but it's still not quite the droids easy GUI-based solution I'm looking for.
So, my question is: Is the a way to quickly and easily insert some data equivalent to the RDBMS method mentioned above?
Make sure you have defined a schema in schema.xml.
SOLR does indeed have a (limited) html GUI, which on a local installation is probably found at localhost:8983/solr (default). If you can get to the base admin page, then on the left there is a small combobox where you can select a core/collection. If you click on THAT, then you get a list of options that emerges, and you can pick 'documents' to get a similar GUI to what I think you expect from postgres/RDBMS/whatnot.
http://localhost:8983/solr/#/collection1/documents is the URL on a default SOLR installation that I have. This should work as long as you don't have default cores. (Replace collection1 with your collection name and localhost:8983 with wherever your solr is hosted/the port).
I am using solrj for a distributed search. Based on certain user preferences, I will have to search through a particular set of indexes. Is there any way through which I can programatically(duh!) specify the datadir for that particular search query?
I did snoop through the documentation, but couldn't find anyway other than having the datasets in different cores, is there a better way?
Edit 1 : All the set of indexes have the same schema format.
You can change the dataDir almost dynamically using the CREATE CoreAdmin action, and specifying a dataDir parameter.
Creates a new core based on preexisting
instanceDir/solrconfig.xml/schema.xml, and registers it. If
persistence is enabled (persist=true), the configuration for this new
core will be saved in 'solr.xml'. If a core with the same name exists,
while the "new" created core is initalizing, the "old" one will
continue to accept requests. Once it has finished, all new request
will go to the "new" core, and the "old" core will be unloaded.
Anyway you'll need to load a new core, it isn't possible changing the data directory without doing it.
You can use solrj to invoke CoreAdmin action using the CoreAdminRequest and CoreAdminResponse classes.
I'm developing an open-source web application (a helpdesk) where the users will download it and install. This application will have some settings like: title, colors, default e-mail, logs... (for example). This settings will be edited by the user on the admin panel because most of them will not understand how to do it in code.
My question is what is the best way to store this on a (MySQL) database model? And counting that this application will upgrade and add more "settings" to that settings table.
Thank you in advance
There are a lot of different ways to do this, and it depends on what you think the final needs will be.
There's nothing wrong with saving parameters in a dedicated table, each parameter/user/value on a separate row. This is a fast way to set and get the information, and allows you to easily get access to reports by parameter and value and user, for example, what colors are the most popular.
If you are just using this for configuration, you can store the parameters as an XML or JSON string in a text/blob field. This has the benefit of giving you a single load to get all of the parameter values. Even more powerful, if your application already has default values for the parameters, you can easily extend the application without changing the database records. For a large number of parameters, this reduces the number of DB calls to load up all the parameters.