Hi everyone, I’m facing a strange internationalization (i18n) issue with a custom Splunk app where German translations are being overwritten by English strings specifically after the dashboard finishes rendering. Environment & Setup Splunk Version: 10.2 App Structure: ...\etc\apps\<app_name>\locale\de_DE\LC_MESSAGES\messages.mo (and .po) Customizations: Dashboards utilize custom JavaScript and CSS. History: This setup worked perfectly a few months ago. No changes have been made to the .po or .mo files since then. The Problem When loading a dashboard via the /de-DE/ locale in the URL, the translation initially works. While the "Loading..." bar is active, the labels correctly appear in German. However, as soon as the searches complete and the dashboard finishes rendering: Custom App Strings: All labels and titles defined in my app’s messages.mo "flicker" and revert back to English. Splunk Default Strings: Core UI elements (menus, loading bars, etc.) stay in German. I’ve confirmed these are correctly pulling from: ...\splunk\appserver\mrsparkle\locale\de_DE\LC_MESSAGES\messages.po It seems like the server-side render is correct, but the client-side UI hand-off is losing the custom app's translation catalog. What I’ve Checked So Far String Matching: Verified msgid strings in the .po file exactly match the XML labels (no extra spaces/case issues). Permissions: All folders and files have correct read permissions. Validation: The initial "flicker" proves the .mo file is being read initially, but it is being overwritten later in the lifecycle. Questions Has anyone seen this "flickering" behavior in Splunk 10.x where custom JS/CSS might interfere with the i18n catalog after the DOM is fully loaded? Are there specific logs (beyond web_service.log) that I can check to see the exact moment these strings are being replaced? Could a recent Splunk version change affect how the client-side UI hydrates the translation catalog for custom apps? Any insights or troubleshooting tips would be greatly appreciated! Thanks, Sanjai ... View more

Hi Splunkers, I’m seeing a “Percentage of small buckets is high” health warning on one of my indexers. The alert shows: 60% small buckets in the last hour 7 out of 9 buckets were small Affected index: _internal (and possibly others) I’ve gone through several community posts, but the guidance and reasons vary across threads. I want to understand this issue clearly for my case and confirm the correct next steps. My Findings So Far (Possible Causes) Indexer restart A restart can force Splunk to roll hot buckets early and create small buckets. Timestamp issues or mixed-time data Bad timestamps or ingesting old + new data at the same time can cause early rolling. Index settings modified If maxDataSize, maxHotBuckets, or other defaults were overridden. Props.conf overwritten Especially if /system/default or local props affecting _internal were modified. Sourcetypes in the _internal index Checked with: index=_internal | stats count by sourcetype Reingesting old data Might trigger early bucket rolls.   What I Want to Confirm Is this mostly a sign of server restart / rolling behavior, or should I suspect timestamp issues even for _internal? Does a simple restart sometimes clear the health status? For _internal, what are the default index settings that should be verified? What is the best way to confirm if props.conf was accidentally overridden for internal logs? What are the most reliable steps to diagnose repeated small bucket creation on an indexer? I also reviewed some older community posts where this behavior was mentioned as a possible Splunk bug (from around 2015). I’m looking for a clear and consolidated explanation and recommended steps specific to a case where _internal is involved and the small bucket percentage is abnormally high. ... View more

Hi Splunk Community, I’m developing a User Management React application using the Splunk React UI framework, intended to be used inside a custom Splunk App. This app uses the REST API (/services/authentication/users) to fetch user details. What I’ve Done: In my local Splunk instance (where users are created manually with Authentication System = Splunk),  for testing the app ,each user object contains a "locked-out" attribute. I use this attribute to determine account status: "locked-out": 0 → User is Active "locked-out": 1 → User is Locked This works as expected in my local environment. The Issue: When testing the same app on a development Splunk instance that uses LDAP authentication, I noticed that LDAP user accounts do not contain the locked-out attribute.   Because of this, my app incorrectly assumes the user is locked (my logic defaults to "Locked" if the attribute is missing). My Questions: Do LDAP or SAML user accounts in Splunk expose any attribute that can be used to determine if the account is locked or active? If not, is there any workaround or recommended practice for this scenario? Is there a capability that allows a logged-in user to view their own authentication context or session info? I’m aware of the edit_user capability, but that allows users to modify other users, which I want to avoid. ( the below image user does't have the Admin role how can it shows the USER AND AUTH menu) Table from custom react app(lists only currently logged in user)   What is the expected behavior when an LDAP or SAML user enters the wrong password multiple times? For Splunk-native users, after several failed login attempts, the "locked-out" attribute is set to 1. For LDAP/SAML users, even after multiple incorrect login attempts, I don’t see any status change or locked-out attribute. Is this expected? Are externally authenticated users (LDAP/SAML) not "locked" in the same way as Splunk-native accounts? Scenario Tested: Logged in with correct username but incorrect password (more than 5 times). Splunk-authenticated user: "locked-out" attribute appears and is set to 1. LDAP-authenticated user: no attribute added or updated; no visible change to user status. Goal: I want the React app to accurately reflect account status for both Splunk-native and LDAP/SAML users. Looking for best practices or alternative approaches for handling this. Let me know if you additional details about my question😊 Thanks in advance, Sanjai😊 ... View more

Hi Splunkers, I recently noticed an issue while opening dashboards—both default and custom app dashboards—in Splunk. I'm encountering a console error that seems to be related to a JavaScript file named layout.js. The error: Failed to load resource: the server responded with a status of 404 (Not Found) :8000/en-US/splunkd/__raw/servicesNS/sanjai/search/static/appLogo.png:1     The screenshots above are taken from the browser’s developer console—specifically the Network tab. I'm unsure why this is occurring, as I haven’t made any recent changes to the static resources. Has anyone else run into a similar issue? Would appreciate any insights! ... View more

Hi Splunkers, I am currently working on a development activity with the Splunk React app and need to get the list of timezones from Splunk into my app. From my research, I found that the list of timezones is located in a file called TimeZones.js at the following path: C:\Program Files\Splunk\quarantined_files\share\splunk\search_mrsparkle\exposed\js\collections\shared\TimeZones.js Questions: How can I retrieve the full list of timezones from the TimeZones.js file? Is there a way to get the timezones via a REST API? Any other suggestions or thoughts on how to achieve this would be appreciated. Thanks in advance! Sanjai ... View more

Hi Splunkers, I received a notice about upgrading jQuery to version 3.5 or higher, and I ran a jQuery scan through the Upgrade Readiness dashboard. The incompatibility issue is coming from my custom app. The file in question: C:\Program Files\Splunk\etc\apps\custom_app\appserver\static\help\en-GB\jquery.js needs to be updated. Remediation(Sugested by the dashboard): The jQuery 1.11.1 bundled with the app introduces vulnerabilities. Splunk apps must use jQuery 3.5 or higher, as lower versions are no longer supported in Splunk Cloud Platform. What I’ve done so far: I downloaded the new jQuery.js file from jquery.com, renamed it, and replaced the file in the specified path and restarted splunk, but this hasn't resolved the upgrade issue. I'm unsure of the next steps and would appreciate any guidance or suggestions. Thanks! Upgrade Readiness App   ... View more

Hi there, I’m currently developing a React app and have almost finished the development. Now, I need to package it as a Splunk app, but I’m stuck on the packaging process. Is there a tool similar to the Splunk App Inspect that can fully inspect the React app I’ve created? Any documentation or blog posts on this would be really helpful. Thanks! ... View more

Hi Splunkers, I’m new to React development and currently working on a React app that handles creating, updating, cloning, and deleting users for a specific Splunk app. The app is working well, but for development purposes, I’ve hardcoded the REST API URL, username, and password. Now, I want to enhance the app so it dynamically uses the current session’s user authentication rather than relying on hardcoded credentials. Here’s the idea I’m aiming for: When a user (e.g., "user1" with admin roles) logs into Splunk, their session credentials (like session key or authentication token) are stored somewhere, right? I need to capture those credentials in my React app. Does this approach make sense? I’m looking for advice on how to retrieve and use the session credentials, token, or session key for the logged-in user in my "User Management" React app. Here’s the current code I’m using to fetch all users (with hardcoded credentials):   // Fetch user data from the API const fetchAllUsers = async () => { try { const response = await axios.get('https://localhost:8089/services/authentication/users', { auth: { username: 'admin', password: 'changeme' }, headers: { 'Content-Type': 'application/xml' } }); // Handle response } catch (error) { console.error('Error fetching users:', error); } }; I also tried retrieving the session key using this cURL command: curl -k https://localhost:8089/services/auth/login --data-urlencode username=admin --data-urlencode password=changeme However, I’m still hardcoding the username and password, which isn’t ideal. My goal is for the React app to automatically use the logged-in user’s session credentials (session key or authentication token) and retrieve the hostname of the deployed environment. Additionally, I’m interested in understanding how core Splunk user management operates and handles authorizations. My current approach might be off, so I’m open to learning the right way to do this. Can anyone guide me on how to achieve this in the "User Management" React app? Any advice or best practices would be greatly appreciated! Thanks in advance! ... View more

Hi Splunker, I’ve been developing a React app for Splunk that manages users via the REST API (create/update/delete). Initially, I hardcoded the REST API URL, username, and password for development purposes. Now that the development is nearly complete, I need to make the URL dynamic. It should retrieve the REST API server URL and the currently logged-in user’s information and use it in the Splunk React app. How can I achieve this? Here is the current hardcoded code: const fetchAllUsers = async () => { try { const response = await axios.get('https://mymachine:8089/services/authentication/users', { auth: { username: 'admin', password: 'admin123' }, headers: { 'Content-Type': 'application/xml' } }); } catch (error) { console.error('Error fetching users:', error); } }; #restapi  #createuser #react #reactapp thanks in advance ... View more