FreeRDP: Redirection to URL with a scheme that is not HTTP(S)

After login with Azure SSO I get a message Redirection to URL with a scheme that is not HTTP(S)

To Reproduce

Steps to reproduce the behavior:

  1. Run:
sdl-freerdp file.rdpw /u:'email' /p:'pass' /sec:nla /cert:ignore +clipboard /gateway:type:arm /network:auto /rfx /gfx:avc444 /dynamic-resolution /log-level:debug

Expected behavior After login with SSO, start using Remote Desktop

Screenshots Partial screenshot:

image

Application details

Compile params:

[13:32:18:251] [111385:0001b319] [DEBUG][com.freerdp.client.common] - [freerdp_client_settings_parse_command_line]: This is 3.0.0-dev3 Build configuration: BUILD_TESTING=ON WINPR_HAVE_AIO_H=1 WINPR_HAVE_EXECINFO_BACKTRACE=1 WINPR_HAVE_EXECINFO_BACKTRACE_SYMBOLS=1 WINPR_HAVE_EXECINFO_BACKTRACE_SYMBOLS_FD=1 WINPR_HAVE_EXECINFO_HEADER=1 WINPR_HAVE_FCNTL_H=1 WINPR_HAVE_GETLOGIN_R=1 WINPR_HAVE_GETPWUID_R=1 WINPR_HAVE_INTTYPES_H=1 WINPR_HAVE_JOURNALD_H=TRUE WINPR_HAVE_POLL_H=1 WINPR_HAVE_PTHREAD_MUTEX_TIMEDLOCK_LIB=1 WINPR_HAVE_PTHREAD_MUTEX_TIMEDLOCK_LIBS= WINPR_HAVE_PTHREAD_MUTEX_TIMEDLOCK_SYMBOL=1 WINPR_HAVE_STDBOOL_H=1 WINPR_HAVE_STDINT_H=1 WINPR_HAVE_STRNDUP=1 WINPR_HAVE_SYSLOG_H=1 WINPR_HAVE_SYS_EVENTFD_H=1 WINPR_HAVE_SYS_FILIO_H= WINPR_HAVE_SYS_SELECT_H=1 WINPR_HAVE_SYS_SOCKIO_H= WINPR_HAVE_SYS_TIMERFD_H=1 WINPR_HAVE_TM_GMTOFF=1 WINPR_HAVE_UNISTD_H=1 WINPR_HAVE_UNWIND_H=1 WITH_AAD=ON WITH_ADD_PLUGIN_TO_RPATH=OFF WITH_ALSA=ON WITH_CAIRO=ON WITH_CCACHE=ON WITH_CHANNELS=ON WITH_CJSON=ON WITH_CLANG_FORMAT=ON WITH_CLIENT=ON WITH_CLIENT_AVAILABLE=1 WITH_CLIENT_CHANNELS=ON WITH_CLIENT_CHANNELS_AVAILABLE=1 WITH_CLIENT_COMMON=ON WITH_CLIENT_INTERFACE=OFF WITH_CLIENT_SDL=ON WITH_CLIENT_SDL_AVAILABLE=1 WITH_CUNIT=ON WITH_CUPS=ON WITH_DEBUG_ALL=OFF WITH_DEBUG_CAPABILITIES=OFF WITH_DEBUG_CERTIFICATE=OFF WITH_DEBUG_CHANNELS=OFF WITH_DEBUG_CLIPRDR=OFF WITH_DEBUG_CODECS=OFF WITH_DEBUG_DVC=OFF WITH_DEBUG_EVENTS=OFF WITH_DEBUG_KBD=OFF WITH_DEBUG_LICENSE=OFF WITH_DEBUG_MUTEX=OFF WITH_DEBUG_NEGO=OFF WITH_DEBUG_NLA=OFF WITH_DEBUG_NTLM=OFF WITH_DEBUG_RAIL=OFF WITH_DEBUG_RDP=OFF WITH_DEBUG_RDPDR=OFF WITH_DEBUG_RDPEI=OFF WITH_DEBUG_RDPGFX=OFF WITH_DEBUG_REDIR=OFF WITH_DEBUG_RFX=OFF WITH_DEBUG_RINGBUFFER=OFF WITH_DEBUG_SCARD=OFF WITH_DEBUG_SCHANNEL=OFF WITH_DEBUG_SDL_EVENTS=OFF WITH_DEBUG_SDL_KBD_EVENTS=OFF WITH_DEBUG_SND=OFF WITH_DEBUG_SVC=OFF WITH_DEBUG_SYMBOLS=OFF WITH_DEBUG_THREADS=OFF WITH_DEBUG_TIMEZONE=OFF WITH_DEBUG_TRANSPORT=OFF WITH_DEBUG_TSG=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_TSMF_AVAILABLE=0 WITH_DEBUG_URBDRC=OFF WITH_DEBUG_WND=OFF WITH_DEBUG_X11=OFF WITH_DEBUG_X11_LOCAL_MOVESIZE=OFF WITH_DEBUG_XV=OFF WITH_DSP_EXPERIMENTAL=OFF WITH_DSP_FFMPEG=ON WITH_DSP_FFMPEG_AVAILABLE=1 WITH_EVENTFD_READ_WRITE=1 WITH_FAAC=OFF WITH_FAAD2=OFF WITH_FFMPEG=ON WITH_FREERDP_DEPRECATED=OFF WITH_FREERDP_DEPRECATED_COMMANDLINE=OFF WITH_FUSE=ON WITH_GFX_H264=ON WITH_GPROF=OFF WITH_GSM=OFF WITH_INTERNAL_MD4=OFF WITH_INTERNAL_MD5=OFF WITH_INTERNAL_RC4=OFF WITH_IPP=OFF WITH_JPEG=ON WITH_KRB5=OFF WITH_LAME=OFF WITH_LIBRARY_VERSIONING=ON WITH_LIBSYSTEMD=ON WITH_LODEPNG=OFF WITH_MACAUDIO=OFF WITH_MACAUDIO_AVAILABLE=0 WITH_MANPAGES=OFF WITH_MBEDTLS=OFF WITH_NATIVE_SSPI=OFF WITH_OPENCL=OFF WITH_OPENH264=TRUE WITH_OPENH264=TRUE WITH_OPENH264_LOADING=OFF WITH_OPENSC_PKCS11_LINKED=OFF WITH_OPENSLES=OFF WITH_OPENSSL=ON WITH_OSS=OFF WITH_PCSC=OFF WITH_PCSC_WINPR=ON WITH_PKCS11=ON WITH_PLATFORM_SERVER=ON WITH_POLL=ON WITH_PROFILER=OFF WITH_PROXY=ON WITH_PROXY_APP=ON WITH_PROXY_EMULATE_SMARTCARD=OFF WITH_PROXY_MODULES=ON WITH_PULSE=OFF WITH_RDTK=ON WITH_SAMPLE=ON WITH_SANITIZE_ADDRESS=OFF WITH_SANITIZE_ADDRESS_AVAILABLE=1 WITH_SANITIZE_MEMORY=OFF WITH_SANITIZE_MEMORY_AVAILABLE=1 WITH_SANITIZE_THREAD=OFF WITH_SANITIZE_THREAD_AVAILABLE=1 WITH_SDL2=ON WITH_SERVER=ON WITH_SERVER_CHANNELS=ON WITH_SERVER_INTERFACE=ON WITH_SHADOW=ON WITH_SMARTCARD_EMULATE=OFF WITH_SMARTCARD_INSPECT=OFF WITH_SMARTCARD_PCSC=ON WITH_SOXR=OFF WITH_SPNEGO=ON WITH_SSE2=ON WITH_SWSCALE=ON WITH_THIRD_PARTY=OFF WITH_UNICODE_BUILTIN=OFF WITH_VAAPI=OFF WITH_VAAPI_AVAILABLE=1 WITH_VALGRIND_MEMCHECK=OFF WITH_VALGRIND_MEMCHECK_AVAILABLE=1 WITH_VERBOSE_WINPR_ASSERT=ON WITH_VIDEO_FFMPEG=ON WITH_VIDEO_FFMPEG_AVAILABLE=1 WITH_WAYLAND=OFF WITH_WEBKIT=ON WITH_WEBVIEW=ON WITH_WEBVIEW_QT=OFF WITH_WINPR_DEPRECATED=OFF WITH_WINPR_TOOLS=ON WITH_WIN_CONSOLE=ON WITH_X11=ON WITH_XCURSOR=ON WITH_XEXT=ON WITH_XFIXES=ON WITH_XI=ON WITH_XINERAMA=ON WITH_XRANDR=ON WITH_XRENDER=ON WITH_XV=ON WITH_ZLIB=ON
Build type:          Release
CFLAGS:               -fPIC -Wall -Wimplicit-function-declaration -Wredundant-decls -fno-omit-frame-pointer
Compiler:            GNU, 12.3.0
Target architecture: x64

Environment (please complete the following information):

  • OS: Linux
  • Version/Distribution: NixOS
  • Architecture: amd64

Additional context

Strange line in the logs:

Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you want WebKit to use a different signal

Even tho I haven’t got into the Remote Desktop session, the CPU usage of this process is huge. (not sure if it is related)

About this issue

  • Original URL
  • State: open
  • Created a year ago
  • Reactions: 3
  • Comments: 17 (7 by maintainers)

Most upvoted comments

@rlees85 did find the reason, fix is part of #9252

@matejc ok. that is tracked with #9189

I’m not sure… xfreerdp uses 0.03% of a CPU generally, obviously this isn’t during media playback. sdl-freerdp was the same not so long ago but now it uses 1 (an entire CPU, all of the time).

It feels like a bug rather than just multi-threading not being implemented. I did try and track down the commit that introduced it but couldn’t. It could also be sdl2 versions.

I’m glad im not the only one experiencing it though