After starting the server with:
./stardog-server.sh start --disable-security --port=8080
Starting stardog
Starting Stardog server in background, see /hd/seel/stardog/stardog//stardog.log for more information.
i was expecting to get a web interface on port 8080. Instead when calling the url on port 8080 a redirect to https://cloud.stardog.com/ happens. This is on an intranet and I do not want to use the cloud service. How can startdog be setup to fullfil this need?
This is the correct behavior. Several major releases ago, Stardog used to have an embedded web console that was superseded by Stardog Studio, and now the other front end tools including Stardog Explorer and Stardog Designer. The redirect is a convenience, as you can sign up for a free account on Stardog Cloud and then "Add Connection" to your self-run instance.
If you are hosting your own Stardog and cannot use the cloud hosted front end applications (e.g. in an air gapped network), Stardog Studio is available via dockerhub to run yourself. The others typically get requested through customer success.
Cheers,
Al
@albaker Thank you for the explanation. I could now start both services successfully. I am running stardog on the default port 5280 and i have successfully used stardog studio in the default configuration. To properly use stardog in my intranet i had to switch off security with
./stardog-server.sh start --disable-security
and now i can't find a way to create a connection from stardog studio since an empty username/password doesn't seem to be accepted.
How can i use stardog studio with a server that has the security disabled?
I have also posted this question on stackoverflow at How to connect stardog studio with stardog server that has security disabled? - Stack Overflow to reach a bigger audience.
This looks like an unintended bug. Studio does both an initial challenge, and then will move over to the bearer token in accordance with other browser auth schemes like oauth2. Unfortunately this means that when the server is started with --disable-security, that also disabled the part of the server that participates in the token flow. Thus, studio can no longer talk to a server that has security disabled. This has been flagged internally, but there is no workaround remedy to enable this configuration with the current version of Studio.
My best advice would be to turn security back on, use the out of the box account (admin/admin), or set your own. Hopefully this isn't too big of a deal, as disable-security is really intended as a minor convenience in a software development environment.
If there are 3rd party software integrations or other environment specific constraints that require disable-security, I would love to discuss that use case with you - feel free to email directly, albaker at stardog
Al
Many months later i am trying to use stardog again. This time it's configured on a new server and i am trying to use stardog studio from a docker image. I have no clue how to make it work i get redirected to the cloud instead of getting proper dialogs and error messages. This is very annoying since it's a repetition of previous behavior. Could you please make sure an attempt to connect to port 5820 actually ends with a proper response on what is going on ...
Hi,
A redirect to Cloud is still the intended behavior when one attempts to navigate to port 5820 in a web browser. You would need to point your browser to the exposed port of your Studio docker image (8888 if you use the docker run command from the documentation) in order to load the Studio javascript. You would then log in to your running Stardog instance on 5820 via the dialog in Studio.