There are three integrated systems needed for authentication in ReactOS:
1. Winlogin
2. MSGINA (ROSGINA would work better, no?)
3. Some sort of Identity Management system with support for local and
remote authentication (remote can come with SMB support later)
Tiers 2 & 3 can be developed and tested on a non ReactOS system (aka a
real Windows system) initially (tho with the code staying in the ROS
Subversion tree), while Tier 1 is ReactOS specific.
I thus see three stages (aligned with the systems mentioned above):
1. Identity Management System with basic tools (get Setup to use it, at
least some basic command line tools to add and remove users and change
passwords, no need for a UI yet)
2. A ROSGINA that uses the Identity Management System
3. Get Winlogin back up and running and using the ROSGINA for
authentication.
Since its stage 1:
The identity management system's sole purpose is to create a
cross-subsystem, ReactOS-wide way to authenticate users. How each
subsystem uses the information provided is up to the individual
subsystem. As such, I see a database (Berkerly DB or Sqlite) of users
(and possibly a separate one with groups) with some basic metadata
describing the user:
1. Username
1. Real Name / Nickname
2. Encrypted Password (encrypted with a choice of algorithms, AES,
Blowfish, etc..)
4. Groups user belongs in (by name)
Any other metadata that should be stored in the authentication database?
The identity management system's API can be quite simple:
BOOL AuthenticateUserA( LPCSTR username, LPCSTR password );
BOOL AuthenticateUserW( LPCWSTR username, LPCWSTR password );
Basically, returning a TRUE if the particular user is valid and FALSE
otherwise. Other APIs to get other metadata can come later?
Any other ideas?
--Justin Haygood
justin.haygood(a)gmail.com
There has been very little activity in 0.3.0, so I am putting out a
last call before feature freeze. If no one comes forward, we will
feature freeze during the weekend so we can start bughunting.
I've also bumped trunk to 0.4.0-SVN, and created an 0.3.0 entry in Bugzilla.
WD
--
ReactOS is a hub, follow the spokes and you'll
immediately find absolutely everything you need
to know about Windows. ReactOS is not just
software, it's people.
kjk_hyperion
I'm interested in translate any article about ReactOs or the ReacOs to
Portuguese.
What article is interesting to Brazilian comunity?
How can I help to translate the ReactOs to Portuguese?
Thanks,
Sandro.
Looks like r22100 breaks the build (at least for me):
[CC] ntoskrnl\cm\ntfunc.c
ntoskrnl\cm\ntfunc.c: In function `NtCreateKey':
ntoskrnl\cm\ntfunc.c:474: warning: implicit declaration of function
`ObpReleaseCapturedName'
make: *** [obj-i386\ntoskrnl\cm\ntfunc.o] Error 1
The ReactOS website frontpage content has remained the same for
several months and it has lead to some confused visitors who has asked
a lot questions in the forums.
We need a high quality text for the frontpage which need to be
reviewed by native speekers. The current text is good, but not
brilliant. There is for example no single line where it states that
ReactOS not using the linux kernel. Or the following sentense is not
optimal: "Finally, a FOSS operating system for everyone!". End-User
does not need to know what "FOSS" is nor any other technical slang.
This are just a few example which shows some downsides of the current
frontpage content.
I am talking about the following page:
http://www.reactos.org/xhtml/en/index.html
... to be exactly, the main part, starting with "ReactOS Project" and
ending with the "W3C" icons.
Please take some time and review the text and post your suggestions
here (ReactOS Mailing List).
The text does not have to have the same length or same
structure/layout. It would be great to have a longer text splitted up
into several sub-topics suitable for a website frontpage.
Visit other website's and compare the content.
To sum up, we need a lot of volunteers (with good english language and
grammar knowledge) who want to help ito improve the ReactOS website.
Even if you are not a native speaker and/or not good in english, you
are welcome to post your suggestions/ideas/etc.
I hope this email will get a lot of response and I am looking forward
to an efficient conversation.
Klemens Friedl
ReactOS Dev & Website Admin
http://www.reactos.org
amunger(a)svn.reactos.org schrieb:
> Author: amunger
> Date: Fri May 26 19:14:13 2006
> New Revision: 22052
>
> URL: http://svn.reactos.ru/svn/reactos?rev=22052&view=rev
> Log:
> Bump trunk to 0.4.0, no turning back now.
Wouldn't it be smater set it to 0.3.1 ? I mean the next version is 0.4.0
actually very unlikely.
Maarten Bosma
Hi,
It is based on Wine implementation. It has other hax with it mostly tests.
There is a hax for NtGdiGetCharABCWidths to allow it to pass one of the
"gdi32_crosstest font" tests.
Over all, it is truly Ugly and going to change. WYSIWUG ATM.
Thanks,
James
I was just looking at the graphics system at many open source
operating systems. Seems to be most of them rely on other engines to
take care of their GUI system. I was thinking what about creating a
GUI or Window Server that draws MPEG2 or MPEG4 compliant graphics.
This implention is wrong please revert it
it shall and must be implement in win32k not direcly to gdi32
NtGdiGetCharWidth
----- Original Message -----
From: <jimtabor(a)svn.reactos.org>
To: <ros-svn(a)reactos.org>
Sent: den 21 January 2006 01:52
Subject: [ros-svn] [jimtabor] 20958: Port Wine GetCharWidth32A.
> Port Wine GetCharWidth32A.
>
>
> Updated files:
> trunk/reactos/lib/gdi32/objects/font.c
>
> _______________________________________________
> Ros-svn mailing list
> Ros-svn(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-svn
I think few of the devs ever read the Design forum (???)
There are a some nice GUI designs, mostly done with a drawing program.
So I thought it would be great to make those designs available inside
ROS. Some of them (I think kokodin made a good and quite good
programmable design) could be done by changing the user32 code, but it's
not a good idea to make theming by changing user32 code. So I had the
following idea: all code really needed to draw the GUI elements could be
exported into an external dll (gui.dll or something like that) so some
basic theming would be pretty easy and still fast. We would only need a
kind of GUI API that would allow changing most things, but would not be
too complex.
What do you think of this?
If you think it's a good idea, I would try to outsource the gui code out
of user32 and try to develop a basic and a secondary (based on kokodin's
design) dll.
