administrators group

apxltd

All right, I'm convinced.... this makes a lot more sense now to do now! I didn't quite realize that Microsoft does not allow non-VSCode clients to connect to their Marketplace, nor did I realize there were so many VSCode forks.

The current plan is to create a new feed type called "Open VSIX" or something that will support connectors. It should also be able to handle the "multi-file packages" (i.e. how the same extension can have multiple .vsix files but different architectures).

We should be able to just reverse engineer the VSIX API as well. That's clearly Open VSIX did; it's not all that complex I think. I've just now updated the other feed types; we don't have a date just yet, but it should e in the coming months. We'll keep this thread up to date.

rhessinger

Hi @joris.guex,

Thanks for the feedback. I think you can see why the original error came to be! I tested with cargo 1.92.0 and the extra seconds did not cause issues in my client. I just updated to 1.97.1 and I was able to recreate the issue. I just created a ticket, PG-3345, to track the fix. There is also a new ProGet 26.0.9-ci.1 image that contains the fix.

Thanks,
Rich

rhessinger

Hi @joris.guex,

Thanks for bringing this to our attention. I have created a ticket, PG-3344, to track the fix and I'll be able to get in in with today's release. Here is a prerelease build of ProGet 2026.8 that includes the fix:

https://proget.inedo.com/containers/tags/ProductImages/inedo/proget/26.0.8-ci.4/overview

Thanks,
Rich

atripp

Hi @brad.zinser ,

This is expected behavior across our products... both the Diagnostic Center and Native API require system/admin-level access, so it's not exposing any information administrators can't already easily see.

Note that, you can also see the API key exposed in standard HTTP access logs as well if you pass via the query string, so the X-ApiKey header may be better anyway.

Thanks,
Alana

rhessinger

Hi @caterina,

Can you navigate to https://«PROGET_HOST»/debug/integrated-auth and send the contents of that page over to us? If need be, you can submit that as a security ticket to us if there is private information in there you do not want to share on the forums.

Can you also try searching for the user using the format of «NETBIOS_DOMAIN_NAME»\«USER_NAME» and verify that mapping is still working?

Thanks,
Rich

stevedennis

Hi @amy.j,

Good news! We've decided to correct this, along with some other errant behavior with carrying over certain server-side metadata from connectors.

We are planning to ship this in the upcoming maintenance release (scheduled for August 7) via PG-3342 (FIX: Ensure correct server-side metadata (publish date, listed, deprecated) is set when adding package via pull, download, or promote from remote connectors).

This is currently in testing / code review now, asit's a bit of a riskier change. But assuming there's no issues with it, it will be available after the release.

Thanks,
Steve

stevedennis

Hi @amy.j ,

This behavior is expected, as the publish date is not carried over via a promotion.

In retrospect, it should have - but this is the sort of behavior we need to be careful about changing in a maintenance release. We'll discuss this internally and decide - please stay tuned, wehope to update by end of next week.

Thanks,
Steve

atripp

Hi @a.sieger ,

I would push back on that "hard requirement" because it doesn't make any technical or business sense, and will only lead to support headaches just like this.

There is something wrong with your PostgreSQL server configuration, perhaps permission related, that's causing the database to not be created. The error cannot be logged in the database because it doesn't exist.

I would delete the database and start again, but verify you've created the database exactly as specified using the exact version supported:
https://docs.inedo.com/docs/installation/postgresql#external-postgres

Things like improper locales will cause errors.

Then, don't run ProGet detached (i.e. ommit -d) so you can get the console logs. That's where you will see database errors. You can also run the upgradedb command instead:
https://docs.inedo.com/docs/installation/linux/installation-upgrading-docker-containers#upgrading-the-database-only-optional

Please let us know what you find!

Hope that helps,
Alana

atripp

@forbzie22_0253 yes it's supported, but please note we are moving away from SQL Server to PostgreSQL, so you should consider migrating (Admin > Database)

atripp

Hi @a.sieger ,

Please note that we do not recommend an external PostgreSQL database. It performs slower, costs more to maintain, has a higher chance of outages, and tends to cause support headaches down the line. The database primarily stores package metadata and application configuration, doesn't take up much disk space, and it's not the business data that your DBAs would own.

That being said if you really insist on using one, then please refer to the Database Connection String section on the page you linked.

For the non-embedded PostgreSQL database backend, you will need to specify a «inedo-product»_POSTGRES_CONNECTION_STRING environment variable instead.

So you need to use PROGET__POSTGRES_CONNECTION_STRING

Thanks,
Alana

administrators

Posts

Member List