Re: pgAdmin4 behind HTTPs

2017-11-22 Thread Stefan Tzeggai

Hi

Am 21.11.2017 um 21:09 schrieb Dave Page:
> 
> 
>> On 21 Nov 2017, at 20:06, Stefan Tzeggai  wrote:
>>
>> Hi
>>
>> I installed pgAdmin4 2.0 in SERVER-Mode. It listens on Port 5050 by default.
>>
>> Now I configured Apache2 to proxy external https access to localhost:5050
>>
>>> ProxyPass / http://localhost:5050/   timeout=600
>>> ProxyPassReverse  / http://localhost:5050/   timeout=600
>>
>> The proxying works, but after some cliks, e.g. after the login, pgAdmin4
>> changes the URL to HTTP without SSL. Hich of course results in an error:
>>
>>> Your browser sent a request that this server could not understand.
>>> Reason: You're speaking plain HTTP to an SSL-enabled server port.
>>> Instead use the HTTPS scheme to access this URL, please.
>>
>>
>> So my question: Is there a way to tell pgAdmin4 that it has an external
>> URL using https ?
>>
>> Thanks
>> Steve
>>
>>
> 
> Can you pinpoint what clicks cause this? I haven’t seen the problem and have 
> a server running this way.

Actually it starts with the login. I have the HTTPS running on this port
554. I click the following links:

https://alfonx.dyndns-ip.com:554/login
 OR
https://alfonx.dyndns-ip.com:554/login?next=%2Fbrowser%2F

Bith both links I get the login page, but after I logged in I end up at:

http://alfonx.dyndns-ip.com:554/  <- NO HTTPS anymore :-(

Greetings
Steve

-- 
empirica-systeme GmbH
Stefan Tzeggai
Brunsstr. 31
72074 Tübingen
email tzeg...@empirica-systeme.de
phone  +49 7071 6392922
mobile +49 176 40 38 9559

"Wer nichts zu verbergen hat, braucht auch keine Hose!"




Re: pgAdmin4 behind HTTPs

2017-11-22 Thread Dave Page
On Wed, Nov 22, 2017 at 8:49 AM, Stefan Tzeggai  wrote:

>
> Hi
>
> Am 21.11.2017 um 21:09 schrieb Dave Page:
> >
> >
> >> On 21 Nov 2017, at 20:06, Stefan Tzeggai 
> wrote:
> >>
> >> Hi
> >>
> >> I installed pgAdmin4 2.0 in SERVER-Mode. It listens on Port 5050 by
> default.
> >>
> >> Now I configured Apache2 to proxy external https access to
> localhost:5050
> >>
> >>> ProxyPass / http://localhost:5050/   timeout=600
> >>> ProxyPassReverse  / http://localhost:5050/   timeout=600
> >>
> >> The proxying works, but after some cliks, e.g. after the login, pgAdmin4
> >> changes the URL to HTTP without SSL. Hich of course results in an error:
> >>
> >>> Your browser sent a request that this server could not understand.
> >>> Reason: You're speaking plain HTTP to an SSL-enabled server port.
> >>> Instead use the HTTPS scheme to access this URL, please.
> >>
> >>
> >> So my question: Is there a way to tell pgAdmin4 that it has an external
> >> URL using https ?
> >>
> >> Thanks
> >> Steve
> >>
> >>
> >
> > Can you pinpoint what clicks cause this? I haven’t seen the problem and
> have a server running this way.
>
> Actually it starts with the login. I have the HTTPS running on this port
> 554. I click the following links:
>
> https://alfonx.dyndns-ip.com:554/login
>  OR
> https://alfonx.dyndns-ip.com:554/login?next=%2Fbrowser%2F
>
> Bith both links I get the login page, but after I logged in I end up at:
>
> http://alfonx.dyndns-ip.com:554/  <- NO HTTPS anymore :-(
>

Does it behave as expected if you run on 443?

FYI, I tried using my docker container (which uses port 443) but mapped it
to 554 on the host, and it seems to stick to https. e.g.

piranha:~ dpage$ docker run -p 554:443 -v
"/Users/dpage/certs/pgadmin.org.pem:/certs/server.cert" -v
"/Users/dpage/certs/pgadmin.org.key:/certs/server.key" -e
"PGADMIN_DEFAULT_EMAIL=u...@domain.com" -e
"PGADMIN_DEFAULT_PASSWORD=SuperSecret" -e "PGADMIN_ENABLE_TLS=True" -e
"PGADMIN_SERVER_NAME=test.pgadmin.org" -d dpage/pgadmin4

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


500 Internal Server Error

2017-11-22 Thread Ben Nachtrieb
Hello,

When I send a query, unexpectedly and seemingly randomly I get the following 
text in the Message tab for the query tool output:

" 500 Internal 
Server Error Internal Server Error The server encountered 
an internal error and was unable to complete your request. Either the server is 
overloaded or there is an error in the application."

Notes:
-The html is part of the message.
-It doesn't seem to matter what query is sent.
-The actual query seems to stay active (as if it is still working), but 
eventually comes back with a wait event: ClientWrite.
-We can remedy the situation by closing the query tool window (hence closing 
the session) and opening a new query too window (whilst never closing pgAdmin 4 
or the connection to the server) then sending the query again.
-We are connected to a Linux VM via my Windows 7 PC.
-This happens probably 10 times a day while queries are being developed and 
tested.

I have:

Version
2.0
Copyright
Copyright 2013 - 2017, The pgAdmin Development Team
Python Version
2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 20:42:59) [MSC v.1500 32 bit (Intel)]
Flask Version
0.12.2
Application Mode
Desktop
Current User
pgadm...@pgadmin.org

What is causing this? What is the fix? Is this a bug? I see similar bugs 
listed, but they all seem to depend on a certain type of query (I think).

Thanks!

Ben



RE: 500 Internal Server Error

2017-11-22 Thread Ben Nachtrieb
Never mind. Found the bug #: Bug #2806
Found here: https://redmine.postgresql.org/issues/2806
Ben Nachtrieb |(303) 350-4287
Only accredited investors and qualified clients will be admitted as limited 
partners to a Crescat fund. For natural persons, investors must meet SEC 
requirements including minimum annual income or net worth thresholds. Crescat 
funds are being offered in reliance on an exemption from the registration 
requirements of the Securities Act of 1933 and are not required to comply with 
specific disclosure requirements that apply to registration under the 
Securities Act. The SEC has not passed upon the merits of or given its approval 
to the Crescat funds, the terms of the offering, or the accuracy or 
completeness of any offering materials. A registration statement has not been 
filed for any Crescat fund with the SEC. Limited partner interests in the 
Crescat funds are subject to legal restrictions on transfer and resale. 
Investors should not assume they will be able to resell their securities. 
Investing in securities involves risk. Investors should be able to bear the 
loss of their investment. Investments in the Crescat funds are not subject to 
the protections of the Investment Company Act of 1940. Performance data 
represents past performance, and past performance does not guarantee future 
results. Performance data is subject to revision following each monthly 
reconciliation and annual audit. Current performance may be lower or higher 
than the performance data presented. Crescat is not required by law to follow 
any standard methodology when calculating and representing performance data. 
The performance of Crescat funds may not be directly comparable to the 
performance of other private or registered funds. Investors may obtain the most 
current performance data and private offering memorandum for a Crescat fund by 
contacting Linda Smith at (303) 271-9997 or by sending a request via email to 
lsm...@crescat.net. See the private offering 
memorandum for each Crescat fund for complete information and risk factors.

From: Ben Nachtrieb
Sent: Wednesday, November 22, 2017 12:32 PM
To: pgadmin-support@lists.postgresql.org
Cc: Ben Nachtrieb 
Subject: 500 Internal Server Error

Hello,

When I send a query, unexpectedly and seemingly randomly I get the following 
text in the Message tab for the query tool output:

" 500 Internal 
Server Error Internal Server Error The server encountered 
an internal error and was unable to complete your request. Either the server is 
overloaded or there is an error in the application."

Notes:
-The html is part of the message.
-It doesn't seem to matter what query is sent.
-The actual query seems to stay active (as if it is still working), but 
eventually comes back with a wait event: ClientWrite.
-We can remedy the situation by closing the query tool window (hence closing 
the session) and opening a new query too window (whilst never closing pgAdmin 4 
or the connection to the server) then sending the query again.
-We are connected to a Linux VM via my Windows 7 PC.
-This happens probably 10 times a day while queries are being developed and 
tested.

I have:

Version
2.0
Copyright
Copyright 2013 - 2017, The pgAdmin Development Team
Python Version
2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 20:42:59) [MSC v.1500 32 bit (Intel)]
Flask Version
0.12.2
Application Mode
Desktop
Current User
pgadm...@pgadmin.org

What is causing this? What is the fix? Is this a bug? I see similar bugs 
listed, but they all seem to depend on a certain type of query (I think).

Thanks!

Ben