Sun Web Application Guidelines - Version 4.1
|
| Search Guidelines | Send Feedback | Developers.sun.com |
How To Use These Guidelines - An Introduction
Appendices > Appendix D
Accessible design allows users with disabilities to use your product. In general, people with visual and motor limitations experience significant barriers with graphical user interfaces (GUIs) because they cannot see the content on the screen, or they cannot manipulate the mouse. Products collectively known as assistive technologies provide alternative control or presentation of the information (or both) with which users interact. For example, a screen reader presents the content of the user interface (UI) to blind users through speech synthesis, a refreshable Braille display, or both.
Broadly speaking, an application is accessible if its UI allows users to customize fonts and colors, and the UI can be controlled or presented (or both) by assistive technologies and a keyboard. For example, applications written with the Swing UI Toolkit are highly accessible because support for the JavaTM Accessibility API (JAAPI) is built into its user interface elements. Swing's UI elements have built-in hooks that allow a screen reader to query them through the JAAPI, and then "read" each element's attributes to the blind user. For example, the hooks make it possible for the user to determine what the name and state of the element with focus is. Similarly to Swing, Web-based applications can utilize HTML's programmatic support for accessibility to enable their content to be accessibly presented through use of the user's browser and assistive technology.
Many users, both with and without disabilities, benefit from accessible design even in the absence of assistive technology. For example, applications that can be operated efficiently from the keyboard (using mnemonics, accelerators, and a logical tab sequence) benefit users who cannot manipulate a mouse. However, they also benefit any users who prefer to use the keyboard for speed. Furthermore, "having a disability" versus "not having a disability" is not a clear distinction. Many people have some temporary or permanent disability, such as repetitive stress injuries, suboptimal near vision, color blindness, and hearing deficits. All of these conditions are present in Sun's user population.
Additional information can be found in 1.4 Resources for Application Designers.
Section 508 of the Federal Rehabilitation Act mandates that all products used by U.S. government agencies must provide "comparable access" for people with disabilities. Virtually all Sun products are sold to the government, so all Sun products must meet Section 508 requirements to maintain and expand sales to this market. In addition to federal agencies, which are required to comply with Section 508 requirements, many state governments and large educational systems are complying voluntarily.
Because Section 508 requirements were designed to allow for progress in technology, the Final Rule listing of the requirements is not an unequivocal functional specification. There is no clear, complete, a priori definition of a GUI that meets the Section 508 standard. In addition to "comparable access," the Final Rule listing includes phrases such as "equivalent facilitation," "fundamental alteration," and "a range of contrast levels," all of which are subject to interpretation. Challenges to particular products, raised by affected individuals, will lead to clarification of the requirements, but only through the lengthy process of addressing such challenges and, potentially, through litigation.
The level of accessibility provided by a product is determined by its development team, as long as the final product meets the requirements of Section 508. In most cases, product support for accessibility can be fit into one of three levels.
Obeying the letter of Section 508 is required, but does not necessarily provide a satisfactory experience for the user. For example, an application with an inaccessible GUI can meet the requirements by providing a command-line interface (CLI) with equivalent or greater functionality. While a CLI may meet the letter of the law, it may be more difficult and time-consuming than the GUI. After all, efficiency of the user is the driving force behind graphical interfaces.
This effort normally results in a better experience for users with disabilities. The improvement largely comes from all users having a common, sharable learning process and working experience. User Friendlier 508 (URL follows) identifies and discusses requirements for a web application to achieve this level, along with helpful external references, including coding guidance. While a Section 508-ready GUI is a better level to aim for, it still doesn't guarantee an interface that is truly usable by people with disabilities.
Whenever feasible, Sun's products should strive to maximize the efficiency of all users. This appendix is a companion piece to User Friendlier 508 and provides additional direction on how to make some common GUI elements delivered by a browser more accessible and usable to the user with a disability.
The World Wide Web Consortium (W3C) has spent many years devising a set of web content accessibility guidelines (WCAG) as part of its Web Accessibility Initiative (WAI). They are available at http://www.w3.org/TR/WCAG10/full-checklist.html.
The WCAG provides guidelines that are separated into three different priority levels. For the most part, Section 508 is a subset of WCAG's set of Priority 1 accessibility guidelines. The WCAG is generally useful to turn to when the application provides a design challenge that isn't covered by this appendix or the User Friendlier 508 web site. Both the WAI guidelines and the guidelines presented here are compatible with Section 508 requirements.
Here are some accessibility tips provided by the World Wide Web Consortium:
It is important to use the HTML tags that most closely represent the desired structure of the page and that the tag structure be consistently used throughout the application. Assistive technologies use this information to determine how the web page should be presented to users. For example:
Screen readers understand the purpose of this markup and know how to present the heading text in a way that notifies the users that a new section has begun. By contrast, section headings could be encoded with the HTML <FONT> and <BR> elements to visually represent the start of a new section however, because improper heading markup is used, the screen reader (and user) won't know if the text presented is regular text or heading text.
Screen readers know how to present list content properly when it sees these HTML elements. In contrast, the HTML <IMG>, <DIV>, and other elements could be used to visually present what looks like a list. However, as with the heading example, the screen reader won't have a programmatically obvious way of knowing when the content being viewed is part of a list.
These are just two possible examples highlighting the importance of using the proper HTML elements when presenting structured content.
Examples of nontext elements include graphics, glyphs, illustrations, and pictures. Regardless of the type of nontext element, always assign an alternate description to it (HTML "ALT" text). Every nontext element needs some sort of alternate description so that the vision-impaired user is able to tell if the information it conveys is important to understanding. Image elements that don't have an alternative description are particularly problematic for vision-impaired users. Their assistive technology, a screen reader, sees the image but can only announce that an unknown image exists. This does not help the user understand the content of the document.
Other guidance to follow for nontext elements is:
A nonessential nontext element, if removed from the content, has no negative impact on the understandability of the rest of the content. One common example of a nonessential element is a bullet graphic that is used in conjunction with a list constructed using the HTML <UL>, <OL>, and <LI> elements.
When a nonsighted or low vision user encounters a form element, he or she must be able to determine the purpose of the element. Form elements that don't include their own visual label attribute should provide a label by adding an HTML <LABEL> element. This visually ties the form element to its label but doesn't do the same programmatically. The result is that the sight-impaired user's assistive technology is unable to accurately determine which label is associated with a specific element. The following guidelines demonstrate how to programmatically associate a label with a form element.
More guidance and examples on how to accessibly code HTML form elements can be found at http://www.access-board.gov/sec508/guide/1194.22.htm#(n). This guidance is compatible with that provided by the W3C.
A common guideline has been to place labels to the left of or above the element it is labeling. This guideline came about to help older screen magnifiers and screen readers that don't recognize the HTML "FOR" attribute on the HTML <LABEL> element. This layout helped the older technologies make more intelligent guesses on which label was naming a given form element. If this label orientation guideline doesn't fit with the desired look and feel of the application, ensure that the design requirement for the look and feel always calls for labels on element classes to be placed consistently in all views of the application.
Content developers frequently group similar page elements together in visual groups. HTML 4.0 provides the elements that allow developers to do so in a programmatically accessible way. Follow these guidelines for grouping these elements together:
Note that the default visual presentation of this element is to draw a box around all the elements in the the group. A style sheet can be used to prevent the drawing of the box.
For usage examples for both these elements, go to http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.10.
Tables can perform two functions in an HTML document: presenting data and specifying page layout. Both are encoded using the same HTML tags, but they have different purposes. Data tables (discussed here) define relationships between the elements they contain. In contrast, layout tables are used solely to arrange items on the screen. For information on layout tables, see D-3.2 Make it Easy to Discern Layout Tables From Data Tables.
Follow these guidelines:
The layout in a web application must be as consistent as possible from page to page. All users have a much easier time learning and using an application that has a consistent presentation, regardless of their experience or disability.
For information on the differences between data tables and layout tables, see D-2.4 How to Encode Data Tables. Follow these guidelines when layout tables are used in an application.
To see the effects of layout tables, set their borders to 10 pixels. This useful test makes the layout tables visible, which simulates how they might appear to users of screen readers.
Application views with multiple frames are defined using <FRAMESET> and related tags. Frames can successfully be used in a manner that meets the requirements of Section 508, but some guidelines must be followed:
The HTML "TITLE" of a frame should denote its purpose, and good examples of frame HTML "TITLE"s include "Table of Contents," "Main Content," and "Masthead Navigation."
Invisible frames are used for various reasons, such as polling a server without causing the entire browser to refresh. HTML "TITLE"s on these frames are important because users working with assistive technologies are likely to "see" each and every frame defined in the <FRAMESET>.
Generally, this guideline means allowing the scrolling or resizing of the frame using the HTML "SCROLLING" attribute, and avoiding the use of the HTML "NORESIZE" attribute. Other issues to address with large text size are discussed in more detail in D-4.3 Accommodate the Use of Larger Font Sizes.
The <NOFRAMES> element and approach was originally introduced to ensure users with browsers or assistive technologies that couldn't parse frames still had access to the content of all frames. Sun products don't need to provide the <NOFRAMES> approach. This is because the user audience for our products has browsers and assistive technologies that can parse frames.
Pop-up windows contain dialog pages and alert messages that appear in addition to the main browser window. In several places in these guidelines, pop-up windows are specified as part of a correct interface. The most notable example is application help.
An example of text that might be entered in the HTML "TITLE" attribute is: "Help Viewer (Opens a New Window)."
All accessibility guidelines, including Section 508, require that web applications respect or inherit the font and color selection that users have set in both their browser and desktop.
This allows users with color sensitivities to change, in a central location, the application's default page colors to color values they can better discern.
This makes it possible for users with limited vision to choose a larger or different font so that they can use the product without needing a separate screen magnifier.
Choose a representative set of pages from the application on which to run this test. Adjust all of the font- and color-related options provided by the browser and desktop. Browsers and desktops place the control panel in a variety of locations, and here are examples of where to look:
Color is a powerful tool, but it must never be used as the sole indicator of the meaning or status of any element. For example, a red bar indicating an error can be used if it is accompanied by additional information, such as an icon with a unique shape or static text.
The following URLs point to helpful information on common types of color blindness and an online color blindness checker.
As web applications become more complex, designing to allow for an enlarged font size becomes more difficult.
Truncation of text and other elements is allowable, provided that the meanings of the elements are maintained and that all functionality is usable.
When the browser does not properly manage fonts that are double the standard size, you must make changes that allow larger fonts to work correctly. Many designs are acceptable, as long as this "double standard size" requirement is met. A common problem occurs when the application uses a navigation frame that does not allow scrollbars. The frame could be made resizable, or empty space could be provided in the frame to accommodate the expanded text.
To determine the standard font size, you must first find all the dialog pages and control panels that affect font specifications. (These panels are the same as those listed in D-4.1 Respect the User's Preference Settings.) Then, set all the font size options to standard settings such as "normal," "medium," "12 points," "12 pixels," or "100%," as appropriate for each option. Once you have set the font size to the standard size, change the document settings by finding the font size options that directly affect the browser, and select a font size that is approximately double the standard size (such as "24" or "Largest").
Style sheets provide the developer and user alike with greater flexibility in the visual presentation of the application. When properly utilized in the application, they allow the developer to define the default look of the application. They also provide the user with a method of changing and fine tuning many more property settings than are available in the browser's property page. This allows a user with a visual impairment to set values that make the application usable for him or her.
Complete this test in conjunction with the tests highlighted in D-4.1 Respect the User's Preference Settings and D-4.3 Accommodate the Use of Larger Font Sizes.
Style sheets provide many features beyond the specification of fonts and colors. These features are implemented differently in different browsers, and they must be used with caution. The choice of style sheet features used in an application is primarily a choice based on which browsers are supported by that application.
Dynamic HTML (DHTML) is a generic term that encompasses any markup that modifies the contents of a browser without contacting the server. The term is not rigorously defined and, in practice, relates only to scripting and layers.
Content generated dynamically in the web page versus being generated by the server is a problem because the new content is transparent to screen readers and smart screen magnifiers. No events are sent out to notify the assistive technology that a change in the page's appearance has occurred.
Web applications are heavily dependent upon scripting, and the only language recommended for use in Sun's products is the JavaScriptTM language. The W3C suggests that scripting be avoided. However, doing so is impossible when you are developing a web-based application. Given the need for such applications, these guidelines help explain how to utilize the JavaScript language in an accessible manner.
The names of these methods are presented to users in the status bars of some browsers and are read aloud to users of screen readers. Because this name is presented to users, it should be considered a public interface and named accordingly.
There are many ways to provide this functionality, and it is not necessary to make every script accessible. For example, the functionality of pop-up menus that appear on a mouseover can be made available as redundant navigation links at the bottom of the page, or by using an onKeyPress() event handler.
More information on developing accessible scripts is provided by the Access Board, the authors of the Section 508 rule, at http://www.access-board.gov/sec508/guide/1194.22.htm#(l).
JavaScript and the Java TM programming language are completely separate entities. Java applets are not covered by these JavaScript requirements.
The use of layers in HTML is becoming more common, but very few accessibility guidelines exist regarding their use.
Technically speaking, servlets and JSPs (Java Server Pages) are not dynamic content. However, they run on the server and send HTML to the browser for display. JSPs and Servlets must be constructed such that the HTML generated by them meets all the requirements specified in Section 508 and this appendix.
Many users cannot use the mouse, so all web applications must be usable solely by using the keyboard.
Utilize the Tab key to perform this test. Verify that the visual indication moves from element to element and is never lost.
The following HTML elements support the HTML "TABINDEX" attribute:
<A>, <AREA>, <BUTTON>, <INPUT>, <OBJECT>, <SELECT>, and <TEXTAREA>.
This URL provides more guidance on how to use the
HTML "TABINDEX" attribute:
http://www.w3.org/TR/REC-html40/interact/forms.html#adef-tabindex.
Important differences exist in how effectively web browsers support keyboard navigation. For example, some versions of Netscape don't allow navigation of all links in a page, even if the page is defined using proper HTML markup. Other browsers do not support keyboard navigation of frames very well. If the web application works well with the keyboard in at least one browser, then the application is meeting the keyboard navigation requirements.
Web content frequently includes regions on web pages devoted solely to site navigation, and these regions are frequently called navigation bars. These regions are typically located at the edges of the main content. The methods typically provided for skipping over these regions are to 1) place the navigation links in a separate frame (for example, a table of contents frame) or 2) to provide a link at the beginning of the navigation bar that, when activated, moves the input focus to the first element after the navigation region. Either method is acceptable, as long as it meets the following guidelines.
The application's right and bottom navigation bars don't usually need to provide a skipping method because their content is typically presented by the user's assistive technology after the application's main content has been presented to the user.
Both methods are invisible to the sighted user, take up no screen real estate, and are visible to the user's assistive technology.
"Skip link #1: to navigation tree"
"Skip link #2: to main content"
In general, always identify the location the skip link will jump to after the colon (for example, "to navigation tree", "to form", "to main content").
The product might be unusable by users with disabilities if the documentation isn't accessible. If the documentation isn't accessible, then the application as a whole does not meet the Section 508 requirements.
An application becomes easy to learn for users with disabilities when it includes information such as how to use the application with the keyboard, how to change the colors used by the application, and how to change the font sizes used by the application. Documentation should, at a minimum:
Individual products should fully document their own user interfaces, including keyboard navigation and shortcuts, command-line interfaces, and so on, in the product's documentation. This information can appear in the user guide, online help, man pages, or in any location where it can be easily found.
The documentation must also include any features specifically aimed at supporting users with disabilities. These features must be fully documented and must be located in a separate accessibility chapter or appendix. Examples of this type of information are built-in magnification for low-vision users and enhancements to the product that improve the behavior of a third-party screen reader.
These features must be documented, but it is not necessary to call them out as accessibility features.
See D-5 Style Sheets for more information on the usage of style sheets in an application.
Web page accessibility checkers are designed to test pages from a variety of different accessibility perspectives, such as Section 508, color blindness, and macular degeneration. The checkers of most general usefulness to web content developers are those that evaluate content against Section 508's web requirements and the W3C's accessibility guidelines.
For web page accessibility checking, the tool InFocus is very useful. This tool was chosen over others because it did a better job of evaluating tables and nontext elements than other similar tools. However, as with all accessibility checkers, it has its weaknesses. For example, analysis of JavaScript code is still rudimentary and a certain amount of human follow-up is often necessary to verify a potential problem. It cannot "certify" that a web application meets Section 508 requirements. These weaknesses exist in all web page accessibility checkers because accessibility, like usability, cannot be verified through a fully automated process.
| Privacy Policy | Terms of Use | Trademarks | Copyright 2007 Sun Microsystems, Inc. |


I have lot more confidence going forward that i have the right doctors and the right treatment plan
If I hadn't gone to FindMeClinic, I could still be waiting for a diagnosis right now.FindMeClinic really saved me
FindMeClinic made all the difference in my decision on what to do for course of treatment..
Their goal was my best care.I feel like FindMeClinic helped save my life...


you better lose yourself lalala lalala lalalallalalal lalalala lalala lalalallalalal lalalalalalalalalalalallalalala


[gecode-users] MinimizeScript: Beginners Question
Christian Schulte
cschulte at kth.se
Tue Jan 17 14:31:56 CET 2012
Hi,
Please let me take your questions in turn.
1. Changing the relation from strict (that is, "<") to a non-strict (that
is, "<=") will typically not work. It would entail that you do not only find
all _optimal_ solutions but all solution for each and every cost value! So
normally that will be way too many solutions! Try it out with Gist on a
small example and you will see that this will make things break down.
Should I add a tip in MPG that the order must be strict for things to work?
2. To find all optimal solutions, I would first find _one_ optimal solution
as normal. Then I would find all solutions (starting a new search) where the
cost value is equal to the optimal const value.
3. You see that printing "all" optimal solutions with respect to 1. and 2.
does not really make much sense.
I hope that helps
Best
Christian
--
Christian Schulte, www.ict.kth.se/~cschulte/
-----Original Message-----
From: users-bounces at gecode.org [mailto:users-bounces at gecode.org] On Behalf
Of Josef Eisl
Sent: Tuesday, January 17, 2012 11:17 AM
To: users at gecode.org
Subject: [gecode-users] MinimizeScript: Beginners Question
Hello,
I am currently modelling my first optimisation problem using Gecode.
Apparently MinimizeScript (as well as MinimizeSpace) consider all solutions,
not only the one with the minimal cost() value.
As far as I understood it, the constraint(Space&) method is used to add
restrictions so that the next solution is better than the current. That
means that the last solution must be the optimal solution.
If I want to find all optimal solutions I have to change constrain form
cost_value < old.cost() to something like cost_value <= old.cost(). Are
these assumptions correct?
Now the real question. Is it possible to configure MinimizeScript in a way
that it only prints the very last (optimal) solution?
Is it possible that the commandline option -solutions is used in respect to
optimal solutions s.t. -solutions 0 means "print all optimal solution",
-solutions 1 "print the first optimal solution" and so on.
I am sorry if the answer to my questions is obvious but I didn't manage to
find it in the docs or mailing list.
Thanks for making such a great piece of software and for keeping it
available for everyone!
br
Josef
_______________________________________________
Gecode users mailing list
users at gecode.org
https://www.gecode.org/mailman/listinfo/gecode-users
More information about the users
mailing list


---
start: 2015-09-23 17:45
edition: 23
participate: "http://www.meetup.com/Chennai-Geek-Night/events/225395865/"
talk: "https://docs.google.com/forms/d/1llJxKCuEnPXOPHnXUQHnc8Unlt_Y4kPvWJqndjl_6Gg/viewform"
subnote: "This event will be live streamed on YouTube."
agenda:
-
time: "6:00"
title: "Stayzilla : moving from a monolithic stack towards a microservice based architecture"
speaker_profile: "By: Arvind Sridharan"
-
time: "6:45"
title: "Break"
-
time: "7:00"
title: "So you think you know Java"
speaker_profile: "By: Bharani Subramaniam"
-
time: "7:30"
title: "React Apps with a Brain"
speaker_profile: "By: Gaurav Agarwal"
-
time: "8:15"
title: "Networking & Dinner"
---


Because I am the only one who worked as software engineer at enterprise, I take the responsibility of designing the system. It is a online ordering and delivery system, and it seams very easy to handle. But when I step into the detail, more and more tough jobs are waiting me to solve.
System structure design I make two assumptions before the system structure designing:
Based on those assumptions, following design features should be considered:
Because it is a business system, reliable, stable, response time and extendable features are considered. Solutions show as bellow:
API and application design Based on the structure introduced above, we build a web host server, MySQL database and program restaurants and dishes CRUD APIs. Pictures are stored on server current, we will transfer the pictures storage to mongo DB in next stage.
The system provides four main distinctive services: Group delivery, hot dishes suggestion and find food by location
In project meeting, we talked a lot services. However, how to implement them using code? We abstract models and actions from the services, define the API of to operate data on remote server and define the operation on client applications.


I'm all packed and ready to go. I'm scheduled to arrive in the DC area tomorrow afternoon, and I should be in Ouagadougou on Wednesday.
All Packed!
It seems a little unreal, but tomorrow is the big day! Everything I think I'll need for over two years is packed away within the Peace Corps luggage allowance, which is two checked bags of up to 50 pounds each, a carry-on bag and a personal item. Tomorrow I'll check in at the Sheraton Tysons Hotel, about ten miles from Dulles airport, and meet the sixty or so other volunteers in training group G34. We'll have a day of training at the Sheraton. I'll also get my shiny new Peace Corps passport! Then, on Tuesday, we go to Dulles, fly to Brussels and then on to Ouagadougou, arriving at about 3 in the afternoon (GMT) in Ouagadougou.
We'll be in Ouagadougou for six days, in a dorm maintained by the Peace Corps. The training schedule has things like “Bike fitting” and “survival language” and – on the day of arrival – “malaria prophylaxis consultations.” We also get to visit the US embassy on Monday the 19th. On Tuesday the 20th, we're bussed 160 km south to Léo, a provincial capital.
We'll all be in the Léo area for about twelve weeks. That's where we learn our local language (which depends on the region), and where I'll get training on how to teach math. I'll be living with a host family for that twelve weeks. At the conclusion of training, on Friday, August 25 we have our swearing-in ceremony in Léo. That's when we graduate from Peace Corps Trainee (PCT) to Peace Corps Volunteer (PCV).
After that, we're sent to our homes for the following two years, which are scattered all over Burkina Faso. Chances are, my nearest fellow volunteer will be an hour or two away from me by bicycle at that point, but there are various meetings and such throughout our service.
No Internet At First
We've been told not to expect to have internet access at first. It might be a week or two before I send out a blog post from Burkina.
The Last Few Months
In retrospect, I'm really glad I quit work a few months ago, and moved out of my place. In a sense, I haven't had a home of my own since then. Indeed, my five weeks in Stasbourg were long enough that I established routines there, such that it was starting to feel like home. Then I left, and came back here to L.A., where I've been staying with my sister, and basically tying up loose ends for the past three weeks. I also ate too much food, watched a lot of TV, and finished that book I didn't want to have to carry to Burkina. That, and I played one last game of ice hockey before leaving!
Anyway, one of the reasons why I'm glad I took this break between work and the Peace Corps is that I think it will reduce my expectations of being able to come back to the US and immediately fit back in. I've been through enough reverse culture shock to intellectually know that coming home can be surprising, but I think my mini-dose after living in Strasbourg for a time will help me understand at a subconscious level. L.A. (under the Trumpocalypse) didn't quite feel like “home” at first, because I had already moved out of the place I had lived for over four years, and because I was a little cut off from current events.
I also had a fantastic time in Europe! Indeed, I can well imagine living there after two or three (or more) years with the Peace Corps. Who knows? Maybe I'll find a development organization I can work with in France, after my Burkinabè experience…
What next?
I really don't know. I don't have too many firm expectations about what life in Burkina will be like, or what I'll do. I know I'm going into a highly structured training for the next three months or so; that kind of relieves me of the need to do too much planning. Also, my idea all along has been to just live there for half a year or more before I try to figure out any kind of longer-range life plan. Indeed, the Peace Corps recommends this: The first three months on site are largely for settling in, getting to know your neighbors, and getting more comfortable with the languages and the culture. I'm a little nervous, but I find I'm perfectly content to just go with the flow for now, and leave the planning for later.


This is the official AtomicDEX mobile beta program channel -
Android: https://play.google.com/store/apps/details?id=com.komodoplatform.atomicdex - iOS: https://testflight.apple.com/join/c2mOLEoC - Please use https://github.com/KomodoPlatform/atomicdex/issues for bug reports and feature requests. For critical security bug reports please do send us your encrypted (https://pgp.mit.edu/pks/lookup?op=get&search=0x379287998EE6CF47) report to<EMAIL_ADDRESS>and allow up to 24h for reply. For atomicDEX API (mm2) related issue reports or feature requests please do use https://github.com/KomodoPlatform/atomicDEX-API/issues
100 messages
Before 05-Dec-19 12:00 AM
TonyL04-Aug-19 01:11 PM
Not finished trade not possible to cancel on stage where balances changing
Only placed order is possible to cancel but order placing itself not changing balance
general_grievous04-Aug-19 01:54 PM
I have canceled the trade and it disappeared from my orders page but some balance has disappeared.
smk762 - dracocanis ominator04-Aug-19 02:42 PM
funds from stalled trade should return in 4.5hours. make note of the uuid and let us know if not
general_grievous04-Aug-19 02:58 PM
I will do so. Thx.
Cryptosaurus04-Aug-19 03:29 PM
When I create an order, after confirmation it changes the amount of receive coin. Anyone else has this issue?
@smk762 - dracocanis ominator is this what is to be expected from the production ready software? 4.5 hours for the funds to return?
TonyL04-Aug-19 04:37 PM
@Cryptosaurus can confirm there is a some not correct behaviour on maker orders creation, thank you for report
@general_grievous such refund time determined by protocol, in these 4.5 hours there is a still a chance to complete swap with this maker. It's very helpful if one of the deal participants have a bad connection lets say
general_grievous04-Aug-19 04:38 PM
Ok. That makes sense.
FtrSaroth04-Aug-19 05:16 PM
Hi @TonyL can i DM you?
TonyL04-Aug-19 06:00 PM
@FtrSaroth Hi, sure
27aume04-Aug-19 06:53 PM
Im getting this error at the moment
t0sma04-Aug-19 07:07 PM
How we can change languages? AtomicDex is in French. I prefer in English.
27aume04-Aug-19 08:12 PM
I had an idea for ethereum based trade and the tx fees.
It would be interesting if a % of eth based trade fees could be directed to a capped pool(c-pool). By c-pool i mean that after for example 10 or 100eth accumulated the fees would stop going in the c-pool.
The c-pool would pay for taker side of trades or maybe both sides (i personally think mainly taker shouldnt have to pay to buy eth or erc20 because if you are trying to get your first eth or simply go from asset to stablecoin its doesnt make sence to send asset to CEX > get eth > withdraw to atomicDex > get what you need)
Thats pretty much it. Thank you
allbits04-Aug-19 08:14 PM
Why should we want to bother fixing a shortcoming that is inherent in eth? Let it suffer from its poor design and be exposed for what it is
3
jspook1604-Aug-19 08:24 PM
Amen
fat3lvis04-Aug-19 08:32 PM
It would be wise to address the eth shortcoming because solutions and simplicity attract users. Complexity for the sake of some “not my mess” attitude is self defeating at best
allbits04-Aug-19 08:42 PM
That's not simplicity. You're further taxing eth transactions, and sending the devs.down a side road. Adding complexity.
Attracting users is not going to be a problem
Gordon Komodo04-Aug-19 09:27 PM
just adding a note informing user about ETH needs gas before trading for first time traders should be sufficient(edited)
D3b004-Aug-19 09:44 PM
What i need to do to get back my kmd ?
花果山04-Aug-19 09:59 PM
@D3b0 The success of the swap is unrecoverable. If it fails, KMD is still in your wallet.
D3b004-Aug-19 10:04 PM
I have 2 timeout and i cant see my kmd for this 2 swap
花果山04-Aug-19 10:46 PM
For timeout orders, you can check if KMD has a rollout record. I also timed out several times, but KMD didn't move in the wallet.
r.05-Aug-19 02:06 AM
Hi. I signed up to be an atomicDex beta tester, but didn't get a link to download the app. Is it allowed for more users to test the application? If so, could anyone help me with this?
TonyL05-Aug-19 03:49 AM
@r. Hi! DM me your email connected to google play store or apple app store (depends of platform on what you want to test) and you'll be added to testers in 1-2 days
gcharang05-Aug-19 07:01 AM
@weldon.gull5 DM me your email connected to google play store or apple app store
花果山05-Aug-19 07:36 AM
@gcharang<EMAIL_ADDRESS>gcharang05-Aug-19 07:38 AM
@花果山 that email is in the list and will be added in the next batch
The Verus Multi-Coin Desktop Wallet. Contribute to VerusCoin/Agama development by creating an account on GitHub.
lollipop05-Aug-19 09:41 AM
Thx
grewalsatinder05-Aug-19 10:06 AM
Just updated and nice to see orders from market! (edited)
1
@ca333 I think there is something minimum amount to use for putting a trade. I remember it was something around 0.00777 something for BTC/KMD order.
It'd be nice to see such info showing on screen somewhere
or is that shown upon trying to place order and it warns on not minimum?
haven't tried another trade since my last one did not complete, the BTC KMD one....
TonyL05-Aug-19 10:18 AM
when you click on "Trade" button with Sell or Receive amount less than 0.00777 you'll see the error message
1
花果山05-Aug-19 10:29 AM
When I place a single order KMD1:100RFOX, the order will appear 1KMD to 0.25RFOX???
jansako05-Aug-19 10:42 AM
The 4 RFOX per KMD is my sell order... I think it is showing you the current best rate on the books.
TonyL05-Aug-19 10:44 AM
When I place a single order KMD1:100RFOX, the order will appear 1KMD to 0.25RFOX??? orders creation feature will be fixed in next release which will be published in a few hours
Example:
!IMG_1568
The positioning of the cursor and the part of the number visible on screen currently make it easy to edit the number but there is no way to see the whole number.
Request: Display the whole number being edited in the field in a smaller font just below it. Update the additional display dynamically as the contents of the field are changed
Is this some kind of a bug?
0.0006 KMD for 0.13 ? While i ordered 29.88(edited)
I cancelled the order until confirmation because i don't feel like swapping 0.13 ETH for 0.0006 KMD only(edited)
TonyL05-Aug-19 04:23 PM
@Sharifa yes, it's a bug. Already fixed and will not persist in the next release
1
Sharifa05-Aug-19 04:50 PM
@TonyL ok thank you for fixing it
TonyL05-Aug-19 04:52 PM
Thank you for report!
1
1
1
fat3lvis05-Aug-19 05:06 PM
I had two swaps time out and now it says that the btc is locked in swaps and not available for trading. The swaps were days ago
Sharifa05-Aug-19 05:32 PM
@TonyL can i also tell you that i tried to test 'withdrawal' to Coinexchange and the address was not valid so i send some ETH back to my Wallet and from there i sended it to my Coinexchange ETH address.
A bug you think?
Werxadler05-Aug-19 06:01 PM
Updated to 0.1.52, still my orders are invisible
TonyL05-Aug-19 06:39 PM
@fat3lvis what version of app on what platrorm are you using? please try to "Log out" from settings and login again
@Werxadler Could you please elaborate - which orders are invisible?
Werxadler05-Aug-19 06:45 PM
@TonyL no matter what, my orderbook is always empty, even if the orders get filled later
TonyL05-Aug-19 06:46 PM
Could you please DM a screenshot?
justpip05-Aug-19 08:30 PM
iPhone SE. Software 12.3.1 – Wouldn't let me set it up beyond the stage of pasting my Seed Phrase.
Some additional feedback:
1. Found the red text on dark grey background (seed phrase) hard to read. This has to be super clear. Not all of us have the eyesight of a 20-year-old
2. Was surprised it was such a short seed (expecting 24 words not 12) so hit the refresh button assuming the second half of the seed phrase was hiding. Realised it wasn't.
Anyways, that's as far as I got before it froze at that stage.
Werxadler05-Aug-19 08:47 PM
@TonyL
TonyL05-Aug-19 08:50 PM
Is there anything on "History" page?
Werxadler05-Aug-19 08:53 PM
Yes, history is normal
And even if the offers not monitored in orders, they got filled 4 times
TonyL05-Aug-19 09:16 PM
Interesting issue, I'm not able to reproduce on my side at the moment. Could you please try to uninstall (at first please ensure that you controller wallet seed and don't have swaps with stucked funds) and reinstall the app? @Werxadler(edited)
Werxadler05-Aug-19 09:38 PM
@TonyL i'll try and give feedback
TonyL05-Aug-19 09:40 PM
Thank you!
Werxadler05-Aug-19 09:54 PM
@TonyL uninstalled and reinstalled, now i can see my orders, but ratio is wrong, it is showing 1/2, my original order was 5/6
TonyL05-Aug-19 09:56 PM
@Werxadler it's a known bug on order creation, will be fixed in next release
Important notice for everyone who builds the atomicDEX-API from source: Rust version was updated https://github.com/KomodoPlatform/atomicDEX-API#how-to-build Please make sure that you install and default the nightly-2019-08-05 before attempting to build the most recent commit.


A Dream of the Future
Oh hi,
You may be wondering what this page is. Just give me access to your Albedo public key :)


We're sorry but parlayes6 doesn't work properly without JavaScript enabled. Please enable it to continue.
ParlayTools.com | #parlaytools


UTC -4
Voltage: 115V
Frequency: 60 Hz
Trinidad and Tobago dollar (TT$).
International Dialing Code for Trinidad Tobago is +1 868.
The Trinidad working & cruisers hailing is VHF channel 68
Cellphone GSM Frequencies: 850/1800/1900 - (This means you will need a GSM cellphone that will work on 850MHz, 1800Mhz, or 1900Mhz to use it in Trinidad and Tobago.)
Digicel update December 2014:
Anyone cruising using Digicel should be aware that if you purchase a SIM card in one country, it cannot be topped up in different one, as previously possible. So if you wish to use the sim bought here while cruising in other countries, you should either put on a large enough sum to cover your needs, or set up an account and do it online.
You can top-up Digicel at https://online-top-up.digicelgroup.com/
The Public Transport Service Corporation of Trinidad and Tobago (PTSC) provides a good transport service. Most routes operate from 5:00 am to 11:00 pm, Monday through Saturday. Sunday service is available from 6:00 am to 10:00 pm on selected routes.
For information on schedules, route maps and fares go to the PTSC website.
Maxi Taxis, private taxis and rental cars are all available.
February - The Trinidad and Tobago Carnival is celebrated two days before Ash Wednesday.
February (mid) - Tobago Carnival Regatta sponsored by the Tobago House of Assembly.
The full schedule of racing events for Trinidad can be found in the racing calendar on the Sailing Association website.
Police - Dial 999
Fire and Ambulance - Dial 990
Ambulance - Dial 811
Reporting Crime - Dial 555
Coast Guard - Dial 634-4440
IMRAY AND ADLARD COLES PILOT BOOKS are available at a discounted price for Noonsite.com users via World Cruising Club.
A Yachtsman’s Guide to Trinidad 3.0
Author Frank Virgintino - Revised January 2016
Available as free pdf download from www.freecruisingguides.com and on Kindle from Amazon and any EPub store.
Provides updated information on clearing rules and fees as well as on the array of facilities and tradespeople that make Trinidad the hurricane season destination with a bonus for cruisers.
A Thinking Mans Guide to Voyages South - the many facets of Caribbean Cruising
Author: Frank Virgintino
Published: 3rd Edition January 2013
Available as a Kindle version at www.amazon.com as well as other EPub bookstores.
The latest edition of this route planner is larger than ever. For more details see this report
The Cruising Guide to Trinidad
By Stephen J. Pavlidis
Publisher: Seaworthy Publications Inc. (November 1, 2002)
ISBN-13:<PHONE_NUMBER>137
A Cruising Guide to Trinidad and Tobago covering this lovely Caribbean cruising region. Its 29 full-color charts containing extremely accurate data are based on independent surveys personally conducted by the author himself, using a computer hydrographic system.
Cruising Guide to Trinidad & Tobago plus Barbados and Guyana
By Chris Doyle and others
Publisher: Cruising Guide Publications (4th Edition Nov 2012)
ISBN: 978-0-944428-96-2
Chris Doyle along with others has explored these islands extensively and offers comprehensive information on a wide variety of facilities. Additionally, the guide also provides information about shore side activities. This edition contains many color photographs and is packed with updated information on navigation and sketch charts with GPS coordinates.
Grenada to the Virgin Islands
By Jacques Patuelli
Publisher Imray Laurie Norie & Wilson- 3rd Edition 2014
ISBN<PHONE_NUMBER>818
This edition covers each island between Grenada and Barbados to the Virgin Islands and is a translation from Jacques Patuelli's original French version with pilotage notes, tourist information, formalities and facilities
Trinidad and Tobago Tourist Board
Trinidad and Tobago Sailing Association
Things I wish I had known before I arrived in Chaguaramas (April 2015)
From Trinidad Cruisers Facebook Group
Yacht Services Association of Trinidad & Tobago
Up to date Statistics and Information on crime against yachts, plus news, information on local marine businesses and much more.
Contact info@ysatt.org


Laravel Passport
- Introduction
- Installation
- Configuration
- Issuing Access Tokens
- Authorization Code Grant with PKCE
- Password Grant Tokens
- Implicit Grant Tokens
- Client Credentials Grant Tokens
- Personal Access Tokens
- Protecting Routes
- Token Scopes
- Consuming Your API With JavaScript
- Events
- Testing
Introduction
Laravel Passport provides a full OAuth2 server implementation for your Laravel application in a matter of minutes. Passport is built on top of the League OAuth2 server that is maintained by Andy Millington and Simon Hamp.
{note} This documentation assumes you are already familiar with OAuth2. If you do not know anything about OAuth2, consider familiarizing yourself with the general terminology and features of OAuth2 before continuing.
Passport Or Sanctum?
Before getting started, you may wish to determine if your application would be better served by Laravel Passport or Laravel Sanctum. If your application absolutely needs to support OAuth2, then you should use Laravel Passport.
However, if you are attempting to authenticate a single-page application, mobile application, or issue API tokens, you should use Laravel Sanctum. Laravel Sanctum does not support OAuth2; however, it provides a much simpler API authentication development experience.
Installation
To get started, install Passport via the Composer package manager:
composer require laravel/passport
Passport's service provider registers its own database migration directory, so you should migrate your database after installing the package. The Passport migrations will create the tables your application needs to store OAuth2 clients and access tokens:
php artisan migrate
Next, you should execute the passport:install
Artisan command. This command will create the encryption keys needed to generate secure access tokens. In addition, the command will create "personal access" and "password grant" clients which will be used to generate access tokens:
php artisan passport:install
{tip} If you would like to use UUIDs as the primary key value of the Passport
Client
model instead of auto-incrementing integers, please install Passport using theuuids
option.
After running the passport:install
command, add the Laravel\Passport\HasApiTokens
trait to your App\Models\User
model. This trait will provide a few helper methods to your model which allow you to inspect the authenticated user's token and scopes:
<?php
namespace App\Models;
use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;
use Laravel\Passport\HasApiTokens;
class User extends Authenticatable
{
use HasApiTokens, HasFactory, Notifiable;
}
Next, you should call the Passport::routes
method within the boot
method of your App\Providers\AuthServiceProvider
. This method will register the routes necessary to issue access tokens and revoke access tokens, clients, and personal access tokens:
<?php
namespace App\Providers;
use Illuminate\Foundation\Support\Providers\AuthServiceProvider as ServiceProvider;
use Illuminate\Support\Facades\Gate;
use Laravel\Passport\Passport;
class AuthServiceProvider extends ServiceProvider
{
/**
* The policy mappings for the application.
*
* @var array
*/
protected $policies = [
'App\Models\Model' => 'App\Policies\ModelPolicy',
];
/**
* Register any authentication / authorization services.
*
* @return void
*/
public function boot()
{
$this->registerPolicies();
Passport::routes();
}
}
Finally, in your application's config/auth.php
configuration file, you should set the driver
option of the api
authentication guard to passport
. This will instruct your application to use Passport's TokenGuard
when authenticating incoming API requests:
'guards' => [
'web' => [
'driver' => 'session',
'provider' => 'users',
],
'api' => [
'driver' => 'passport',
'provider' => 'users',
],
],
Client UUIDs
You may also run the passport:install
command with the --uuids
option present. This option will instruct Passport that you would like to use UUIDs instead of auto-incrementing integers as the Passport Client
model's primary key values. After running the passport:install
command with the --uuids
option, you will be given additional instructions regarding disabling Passport's default migrations:
php artisan passport:install --uuids
Deploying Passport
When deploying Passport to your application's servers for the first time, you will likely need to run the passport:keys
command. This command generates the encryption keys Passport needs in order to generate access tokens. The generated keys are not typically kept in source control:
php artisan passport:keys
If necessary, you may define the path where Passport's keys should be loaded from. You may use the Passport::loadKeysFrom
method to accomplish this. Typically, this method should be called from the boot
method of your application's App\Providers\AuthServiceProvider
class:
/**
* Register any authentication / authorization services.
*
* @return void
*/
public function boot()
{
$this->registerPolicies();
Passport::routes();
Passport::loadKeysFrom(__DIR__.'/../secrets/oauth');
}
Loading Keys From The Environment
Alternatively, you may publish Passport's configuration file using the vendor:publish
Artisan command:
php artisan vendor:publish --tag=passport-config
After the configuration file has been published, you may load your application's encryption keys by defining them as environment variables:
PASSPORT_PRIVATE_KEY="-----BEGIN RSA PRIVATE KEY-----
<private key here>
-----END RSA PRIVATE KEY-----"
PASSPORT_PUBLIC_KEY="-----BEGIN PUBLIC KEY-----
<public key here>
-----END PUBLIC KEY-----"
Migration Customization
If you are not going to use Passport's default migrations, you should call the Passport::ignoreMigrations
method in the register
method of your App\Providers\AppServiceProvider
class. You may export the default migrations using the vendor:publish
Artisan command:
php artisan vendor:publish --tag=passport-migrations
Upgrading Passport
When upgrading to a new major version of Passport, it's important that you carefully review the upgrade guide.
Configuration
Client Secret Hashing
If you would like your client's secrets to be hashed when stored in your database, you should call the Passport::hashClientSecrets
method in the boot
method of your App\Providers\AuthServiceProvider
class:
use Laravel\Passport\Passport;
Passport::hashClientSecrets();
Once enabled, all of your client secrets will only be displayable to the user immediately after they are created. Since the plain-text client secret value is never stored in the database, it is not possible to recover the secret's value if it is lost.
Token Lifetimes
By default, Passport issues long-lived access tokens that expire after one year. If you would like to configure a longer / shorter token lifetime, you may use the tokensExpireIn
, refreshTokensExpireIn
, and personalAccessTokensExpireIn
methods. These methods should be called from the boot
method of your application's App\Providers\AuthServiceProvider
class:
/**
* Register any authentication / authorization services.
*
* @return void
*/
public function boot()
{
$this->registerPolicies();
Passport::routes();
Passport::tokensExpireIn(now()->addDays(15));
Passport::refreshTokensExpireIn(now()->addDays(30));
Passport::personalAccessTokensExpireIn(now()->addMonths(6));
}
{note} The
expires_at
columns on Passport's database tables are read-only and for display purposes only. When issuing tokens, Passport stores the expiration information within the signed and encrypted tokens. If you need to invalidate a token you should revoke it.
Overriding Default Models
You are free to extend the models used internally by Passport by defining your own model and extending the corresponding Passport model:
use Laravel\Passport\Client as PassportClient;
class Client extends PassportClient
{
// ...
}
After defining your model, you may instruct Passport to use your custom model via the Laravel\Passport\Passport
class. Typically, you should inform Passport about your custom models in the boot
method of your application's App\Providers\AuthServiceProvider
class:
use App\Models\Passport\AuthCode;
use App\Models\Passport\Client;
use App\Models\Passport\PersonalAccessClient;
use App\Models\Passport\Token;
/**
* Register any authentication / authorization services.
*
* @return void
*/
public function boot()
{
$this->registerPolicies();
Passport::routes();
Passport::useTokenModel(Token::class);
Passport::useClientModel(Client::class);
Passport::useAuthCodeModel(AuthCode::class);
Passport::usePersonalAccessClientModel(PersonalAccessClient::class);
}
Issuing Access Tokens
Using OAuth2 via authorization codes is how most developers are familiar with OAuth2. When using authorization codes, a client application will redirect a user to your server where they will either approve or deny the request to issue an access token to the client.
Managing Clients
First, developers building applications that need to interact with your application's API will need to register their application with yours by creating a "client". Typically, this consists of providing the name of their application and a URL that your application can redirect to after users approve their request for authorization.
The passport:client
Command
The simplest way to create a client is using the passport:client
Artisan command. This command may be used to create your own clients for testing your OAuth2 functionality. When you run the client
command, Passport will prompt you for more information about your client and will provide you with a client ID and secret:
php artisan passport:client
Redirect URLs
If you would like to allow multiple redirect URLs for your client, you may specify them using a comma-delimited list when prompted for the URL by the passport:client
command. Any URLs which contain commas should be URL encoded:
http://example.com/callback,http://examplefoo.com/callback
JSON API
Since your application's users will not be able to utilize the client
command, Passport provides a JSON API that you may use to create clients. This saves you the trouble of having to manually code controllers for creating, updating, and deleting clients.
However, you will need to pair Passport's JSON API with your own frontend to provide a dashboard for your users to manage their clients. Below, we'll review all of the API endpoints for managing clients. For convenience, we'll use Axios to demonstrate making HTTP requests to the endpoints.
The JSON API is guarded by the web
and auth
middleware; therefore, it may only be called from your own application. It is not able to be called from an external source.
GET /oauth/clients
This route returns all of the clients for the authenticated user. This is primarily useful for listing all of the user's clients so that they may edit or delete them:
axios.get('/oauth/clients')
.then(response => {
console.log(response.data);
});
POST /oauth/clients
This route is used to create new clients. It requires two pieces of data: the client's name
and a redirect
URL. The redirect
URL is where the user will be redirected after approving or denying a request for authorization.
When a client is created, it will be issued a client ID and client secret. These values will be used when requesting access tokens from your application. The client creation route will return the new client instance:
const data = {
name: 'Client Name',
redirect: 'http://example.com/callback'
};
axios.post('/oauth/clients', data)
.then(response => {
console.log(response.data);
})
.catch (response => {
// List errors on response...
});
PUT /oauth/clients/{client-id}
This route is used to update clients. It requires two pieces of data: the client's name
and a redirect
URL. The redirect
URL is where the user will be redirected after approving or denying a request for authorization. The route will return the updated client instance:
const data = {
name: 'New Client Name',
redirect: 'http://example.com/callback'
};
axios.put('/oauth/clients/' + clientId, data)
.then(response => {
console.log(response.data);
})
.catch (response => {
// List errors on response...
});
DELETE /oauth/clients/{client-id}
This route is used to delete clients:
axios.delete('/oauth/clients/' + clientId)
.then(response => {
//
});
Requesting Tokens
Redirecting For Authorization
Once a client has been created, developers may use their client ID and secret to request an authorization code and access token from your application. First, the consuming application should make a redirect request to your application's /oauth/authorize
route like so:
use Illuminate\Http\Request;
use Illuminate\Support\Str;
Route::get('/redirect', function (Request $request) {
$request->session()->put('state', $state = Str::random(40));
$query = http_build_query([
'client_id' => 'client-id',
'redirect_uri' => 'http://third-party-app.com/callback',
'response_type' => 'code',
'scope' => '',
'state' => $state,
]);
return redirect('http://passport-app.com/oauth/authorize?'.$query);
});
{tip} Remember, the
/oauth/authorize
route is already defined by thePassport::routes
method. You do not need to manually define this route.
Approving The Request
When receiving authorization requests, Passport will automatically display a template to the user allowing them to approve or deny the authorization request. If they approve the request, they will be redirected back to the redirect_uri
that was specified by the consuming application. The redirect_uri
must match the redirect
URL that was specified when the client was created.
If you would like to customize the authorization approval screen, you may publish Passport's views using the vendor:publish
Artisan command. The published views will be placed in the resources/views/vendor/passport
directory:
php artisan vendor:publish --tag=passport-views
Sometimes you may wish to skip the authorization prompt, such as when authorizing a first-party client. You may accomplish this by extending the Client
model and defining a skipsAuthorization
method. If skipsAuthorization
returns true
the client will be approved and the user will be redirected back to the redirect_uri
immediately:
<?php
namespace App\Models\Passport;
use Laravel\Passport\Client as BaseClient;
class Client extends BaseClient
{
/**
* Determine if the client should skip the authorization prompt.
*
* @return bool
*/
public function skipsAuthorization()
{
return $this->firstParty();
}
}
Converting Authorization Codes To Access Tokens
If the user approves the authorization request, they will be redirected back to the consuming application. The consumer should first verify the state
parameter against the value that was stored prior to the redirect. If the state parameter matches then the consumer should issue a POST
request to your application to request an access token. The request should include the authorization code that was issued by your application when the user approved the authorization request:
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Http;
Route::get('/callback', function (Request $request) {
$state = $request->session()->pull('state');
throw_unless(
strlen($state) > 0 && $state === $request->state,
InvalidArgumentException::class
);
$response = Http::asForm()->post('http://passport-app.com/oauth/token', [
'grant_type' => 'authorization_code',
'client_id' => 'client-id',
'client_secret' => 'client-secret',
'redirect_uri' => 'http://third-party-app.com/callback',
'code' => $request->code,
]);
return $response->json();
});
This /oauth/token
route will return a JSON response containing access_token
, refresh_token
, and expires_in
attributes. The expires_in
attribute contains the number of seconds until the access token expires.
{tip} Like the
/oauth/authorize
route, the/oauth/token
route is defined for you by thePassport::routes
method. There is no need to manually define this route.
JSON API
Passport also includes a JSON API for managing authorized access tokens. You may pair this with your own frontend to offer your users a dashboard for managing access tokens. For convenience, we'll use Axios to demonstrate making HTTP requests to the endpoints. The JSON API is guarded by the web
and auth
middleware; therefore, it may only be called from your own application.
GET /oauth/tokens
This route returns all of the authorized access tokens that the authenticated user has created. This is primarily useful for listing all of the user's tokens so that they can revoke them:
axios.get('/oauth/tokens')
.then(response => {
console.log(response.data);
});
DELETE /oauth/tokens/{token-id}
This route may be used to revoke authorized access tokens and their related refresh tokens:
axios.delete('/oauth/tokens/' + tokenId);
Refreshing Tokens
If your application issues short-lived access tokens, users will need to refresh their access tokens via the refresh token that was provided to them when the access token was issued:
use Illuminate\Support\Facades\Http;
$response = Http::asForm()->post('http://passport-app.com/oauth/token', [
'grant_type' => 'refresh_token',
'refresh_token' => 'the-refresh-token',
'client_id' => 'client-id',
'client_secret' => 'client-secret',
'scope' => '',
]);
return $response->json();
This /oauth/token
route will return a JSON response containing access_token
, refresh_token
, and expires_in
attributes. The expires_in
attribute contains the number of seconds until the access token expires.
Revoking Tokens
You may revoke a token by using the revokeAccessToken
method on the Laravel\Passport\TokenRepository
. You may revoke a token's refresh tokens using the revokeRefreshTokensByAccessTokenId
method on the Laravel\Passport\RefreshTokenRepository
. These classes may be resolved using Laravel's service container:
use Laravel\Passport\TokenRepository;
use Laravel\Passport\RefreshTokenRepository;
$tokenRepository = app(TokenRepository::class);
$refreshTokenRepository = app(RefreshTokenRepository::class);
// Revoke an access token...
$tokenRepository->revokeAccessToken($tokenId);
// Revoke all of the token's refresh tokens...
$refreshTokenRepository->revokeRefreshTokensByAccessTokenId($tokenId);
Purging Tokens
When tokens have been revoked or expired, you might want to purge them from the database. Passport's included passport:purge
Artisan command can do this for you:
# Purge revoked and expired tokens and auth codes...
php artisan passport:purge
# Only purge revoked tokens and auth codes...
php artisan passport:purge --revoked
# Only purge expired tokens and auth codes...
php artisan passport:purge --expired
You may also configure a scheduled job in your application's App\Console\Kernel
class to automatically prune your tokens on a schedule:
/**
* Define the application's command schedule.
*
* @param \Illuminate\Console\Scheduling\Schedule $schedule
* @return void
*/
protected function schedule(Schedule $schedule)
{
$schedule->command('passport:purge')->hourly();
}
Authorization Code Grant with PKCE
The Authorization Code grant with "Proof Key for Code Exchange" (PKCE) is a secure way to authenticate single page applications or native applications to access your API. This grant should be used when you can't guarantee that the client secret will be stored confidentially or in order to mitigate the threat of having the authorization code intercepted by an attacker. A combination of a "code verifier" and a "code challenge" replaces the client secret when exchanging the authorization code for an access token.
Creating The Client
Before your application can issue tokens via the authorization code grant with PKCE, you will need to create a PKCE-enabled client. You may do this using the passport:client
Artisan command with the --public
option:
php artisan passport:client --public
Requesting Tokens
Code Verifier & Code Challenge
As this authorization grant does not provide a client secret, developers will need to generate a combination of a code verifier and a code challenge in order to request a token.
The code verifier should be a random string of between 43 and 128 characters containing letters, numbers, and "-"
, "."
, "_"
, "~"
characters, as defined in the RFC 7636 specification.
The code challenge should be a Base64 encoded string with URL and filename-safe characters. The trailing '='
characters should be removed and no line breaks, whitespace, or other additional characters should be present.
$encoded = base64_encode(hash('sha256', $code_verifier, true));
$codeChallenge = strtr(rtrim($encoded, '='), '+/', '-_');
Redirecting For Authorization
Once a client has been created, you may use the client ID and the generated code verifier and code challenge to request an authorization code and access token from your application. First, the consuming application should make a redirect request to your application's /oauth/authorize
route:
use Illuminate\Http\Request;
use Illuminate\Support\Str;
Route::get('/redirect', function (Request $request) {
$request->session()->put('state', $state = Str::random(40));
$request->session()->put(
'code_verifier', $code_verifier = Str::random(128)
);
$codeChallenge = strtr(rtrim(
base64_encode(hash('sha256', $code_verifier, true))
, '='), '+/', '-_');
$query = http_build_query([
'client_id' => 'client-id',
'redirect_uri' => 'http://third-party-app.com/callback',
'response_type' => 'code',
'scope' => '',
'state' => $state,
'code_challenge' => $codeChallenge,
'code_challenge_method' => 'S256',
]);
return redirect('http://passport-app.com/oauth/authorize?'.$query);
});
Converting Authorization Codes To Access Tokens
If the user approves the authorization request, they will be redirected back to the consuming application. The consumer should verify the state
parameter against the value that was stored prior to the redirect, as in the standard Authorization Code Grant.
If the state parameter matches, the consumer should issue a POST
request to your application to request an access token. The request should include the authorization code that was issued by your application when the user approved the authorization request along with the originally generated code verifier:
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Http;
Route::get('/callback', function (Request $request) {
$state = $request->session()->pull('state');
$codeVerifier = $request->session()->pull('code_verifier');
throw_unless(
strlen($state) > 0 && $state === $request->state,
InvalidArgumentException::class
);
$response = Http::asForm()->post('http://passport-app.com/oauth/token', [
'grant_type' => 'authorization_code',
'client_id' => 'client-id',
'redirect_uri' => 'http://third-party-app.com/callback',
'code_verifier' => $codeVerifier,
'code' => $request->code,
]);
return $response->json();
});
Password Grant Tokens
The OAuth2 password grant allows your other first-party clients, such as a mobile application, to obtain an access token using an email address / username and password. This allows you to issue access tokens securely to your first-party clients without requiring your users to go through the entire OAuth2 authorization code redirect flow.
Creating A Password Grant Client
Before your application can issue tokens via the password grant, you will need to create a password grant client. You may do this using the passport:client
Artisan command with the --password
option. If you have already run the passport:install
command, you do not need to run this command:
php artisan passport:client --password
Requesting Tokens
Once you have created a password grant client, you may request an access token by issuing a POST
request to the /oauth/token
route with the user's email address and password. Remember, this route is already registered by the Passport::routes
method so there is no need to define it manually. If the request is successful, you will receive an access_token
and refresh_token
in the JSON response from the server:
use Illuminate\Support\Facades\Http;
$response = Http::asForm()->post('http://passport-app.com/oauth/token', [
'grant_type' => 'password',
'client_id' => 'client-id',
'client_secret' => 'client-secret',
'username' =><EMAIL_ADDRESS>'password' => 'my-password',
'scope' => '',
]);
return $response->json();
{tip} Remember, access tokens are long-lived by default. However, you are free to configure your maximum access token lifetime if needed.
Requesting All Scopes
When using the password grant or client credentials grant, you may wish to authorize the token for all of the scopes supported by your application. You can do this by requesting the *
scope. If you request the *
scope, the can
method on the token instance will always return true
. This scope may only be assigned to a token that is issued using the password
or client_credentials
grant:
use Illuminate\Support\Facades\Http;
$response = Http::asForm()->post('http://passport-app.com/oauth/token', [
'grant_type' => 'password',
'client_id' => 'client-id',
'client_secret' => 'client-secret',
'username' =><EMAIL_ADDRESS>'password' => 'my-password',
'scope' => '*',
]);
Customizing The User Provider
If your application uses more than one authentication user provider, you may specify which user provider the password grant client uses by providing a --provider
option when creating the client via the artisan passport:client --password
command. The given provider name should match a valid provider defined in your application's config/auth.php
configuration file. You can then protect your route using middleware to ensure that only users from the guard's specified provider are authorized.
Customizing The Username Field
When authenticating using the password grant, Passport will use the email
attribute of your authenticatable model as the "username". However, you may customize this behavior by defining a findForPassport
method on your model:
<?php
namespace App\Models;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;
use Laravel\Passport\HasApiTokens;
class User extends Authenticatable
{
use HasApiTokens, Notifiable;
/**
* Find the user instance for the given username.
*
* @param string $username
* @return \App\Models\User
*/
public function findForPassport($username)
{
return $this->where('username', $username)->first();
}
}
Customizing The Password Validation
When authenticating using the password grant, Passport will use the password
attribute of your model to validate the given password. If your model does not have a password
attribute or you wish to customize the password validation logic, you can define a validateForPassportPasswordGrant
method on your model:
<?php
namespace App\Models;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;
use Illuminate\Support\Facades\Hash;
use Laravel\Passport\HasApiTokens;
class User extends Authenticatable
{
use HasApiTokens, Notifiable;
/**
* Validate the password of the user for the Passport password grant.
*
* @param string $password
* @return bool
*/
public function validateForPassportPasswordGrant($password)
{
return Hash::check($password, $this->password);
}
}
Implicit Grant Tokens
The implicit grant is similar to the authorization code grant; however, the token is returned to the client without exchanging an authorization code. This grant is most commonly used for JavaScript or mobile applications where the client credentials can't be securely stored. To enable the grant, call the enableImplicitGrant
method in the boot
method of your applications's App\Providers\AuthServiceProvider
class:
/**
* Register any authentication / authorization services.
*
* @return void
*/
public function boot()
{
$this->registerPolicies();
Passport::routes();
Passport::enableImplicitGrant();
}
Once the grant has been enabled, developers may use their client ID to request an access token from your application. The consuming application should make a redirect request to your application's /oauth/authorize
route like so:
use Illuminate\Http\Request;
Route::get('/redirect', function (Request $request) {
$request->session()->put('state', $state = Str::random(40));
$query = http_build_query([
'client_id' => 'client-id',
'redirect_uri' => 'http://third-party-app.com/callback',
'response_type' => 'token',
'scope' => '',
'state' => $state,
]);
return redirect('http://passport-app.com/oauth/authorize?'.$query);
});
{tip} Remember, the
/oauth/authorize
route is already defined by thePassport::routes
method. You do not need to manually define this route.
Client Credentials Grant Tokens
The client credentials grant is suitable for machine-to-machine authentication. For example, you might use this grant in a scheduled job which is performing maintenance tasks over an API.
Before your application can issue tokens via the client credentials grant, you will need to create a client credentials grant client. You may do this using the --client
option of the passport:client
Artisan command:
php artisan passport:client --client
Next, to use this grant type, you need to add the CheckClientCredentials
middleware to the $routeMiddleware
property of your app/Http/Kernel.php
file:
use Laravel\Passport\Http\Middleware\CheckClientCredentials;
protected $routeMiddleware = [
'client' => CheckClientCredentials::class,
];
Then, attach the middleware to a route:
Route::get('/orders', function (Request $request) {
...
})->middleware('client');
To restrict access to the route to specific scopes, you may provide a comma-delimited list of the required scopes when attaching the client
middleware to the route:
Route::get('/orders', function (Request $request) {
...
})->middleware('client:check-status,your-scope');
Retrieving Tokens
To retrieve a token using this grant type, make a request to the oauth/token
endpoint:
use Illuminate\Support\Facades\Http;
$response = Http::asForm()->post('http://passport-app.com/oauth/token', [
'grant_type' => 'client_credentials',
'client_id' => 'client-id',
'client_secret' => 'client-secret',
'scope' => 'your-scope',
]);
return $response->json()['access_token'];
Personal Access Tokens
Sometimes, your users may want to issue access tokens to themselves without going through the typical authorization code redirect flow. Allowing users to issue tokens to themselves via your application's UI can be useful for allowing users to experiment with your API or may serve as a simpler approach to issuing access tokens in general.
Creating A Personal Access Client
Before your application can issue personal access tokens, you will need to create a personal access client. You may do this by executing the passport:client
Artisan command with the --personal
option. If you have already run the passport:install
command, you do not need to run this command:
php artisan passport:client --personal
After creating your personal access client, place the client's ID and plain-text secret value in your application's .env
file:
PASSPORT_PERSONAL_ACCESS_CLIENT_ID="client-id-value"
PASSPORT_PERSONAL_ACCESS_CLIENT_SECRET="unhashed-client-secret-value"
Managing Personal Access Tokens
Once you have created a personal access client, you may issue tokens for a given user using the createToken
method on the App\Models\User
model instance. The createToken
method accepts the name of the token as its first argument and an optional array of scopes as its second argument:
use App\Models\User;
$user = User::find(1);
// Creating a token without scopes...
$token = $user->createToken('Token Name')->accessToken;
// Creating a token with scopes...
$token = $user->createToken('My Token', ['place-orders'])->accessToken;
JSON API
Passport also includes a JSON API for managing personal access tokens. You may pair this with your own frontend to offer your users a dashboard for managing personal access tokens. Below, we'll review all of the API endpoints for managing personal access tokens. For convenience, we'll use Axios to demonstrate making HTTP requests to the endpoints.
The JSON API is guarded by the web
and auth
middleware; therefore, it may only be called from your own application. It is not able to be called from an external source.
GET /oauth/scopes
This route returns all of the scopes defined for your application. You may use this route to list the scopes a user may assign to a personal access token:
axios.get('/oauth/scopes')
.then(response => {
console.log(response.data);
});
GET /oauth/personal-access-tokens
This route returns all of the personal access tokens that the authenticated user has created. This is primarily useful for listing all of the user's tokens so that they may edit or revoke them:
axios.get('/oauth/personal-access-tokens')
.then(response => {
console.log(response.data);
});
POST /oauth/personal-access-tokens
This route creates new personal access tokens. It requires two pieces of data: the token's name
and the scopes
that should be assigned to the token:
const data = {
name: 'Token Name',
scopes: []
};
axios.post('/oauth/personal-access-tokens', data)
.then(response => {
console.log(response.data.accessToken);
})
.catch (response => {
// List errors on response...
});
DELETE /oauth/personal-access-tokens/{token-id}
This route may be used to revoke personal access tokens:
axios.delete('/oauth/personal-access-tokens/' + tokenId);
Protecting Routes
Via Middleware
Passport includes an authentication guard that will validate access tokens on incoming requests. Once you have configured the api
guard to use the passport
driver, you only need to specify the auth:api
middleware on any routes that should require a valid access token:
Route::get('/user', function () {
//
})->middleware('auth:api');
Multiple Authentication Guards
If your application authenticates different types of users that perhaps use entirely different Eloquent models, you will likely need to define a guard configuration for each user provider type in your application. This allows you to protect requests intended for specific user providers. For example, given the following guard configuration the config/auth.php
configuration file:
'api' => [
'driver' => 'passport',
'provider' => 'users',
],
'api-customers' => [
'driver' => 'passport',
'provider' => 'customers',
],
The following route will utilize the api-customers
guard, which uses the customers
user provider, to authenticate incoming requests:
Route::get('/customer', function () {
//
})->middleware('auth:api-customers');
{tip} For more information on using multiple user providers with Passport, please consult the password grant documentation.
Passing The Access Token
When calling routes that are protected by Passport, your application's API consumers should specify their access token as a Bearer
token in the Authorization
header of their request. For example, when using the Guzzle HTTP library:
use Illuminate\Support\Facades\Http;
$response = Http::withHeaders([
'Accept' => 'application/json',
'Authorization' => 'Bearer '.$accessToken,
])->get('https://passport-app.com/api/user');
return $response->json();
Token Scopes
Scopes allow your API clients to request a specific set of permissions when requesting authorization to access an account. For example, if you are building an e-commerce application, not all API consumers will need the ability to place orders. Instead, you may allow the consumers to only request authorization to access order shipment statuses. In other words, scopes allow your application's users to limit the actions a third-party application can perform on their behalf.
Defining Scopes
You may define your API's scopes using the Passport::tokensCan
method in the boot
method of your application's App\Providers\AuthServiceProvider
class. The tokensCan
method accepts an array of scope names and scope descriptions. The scope description may be anything you wish and will be displayed to users on the authorization approval screen:
/**
* Register any authentication / authorization services.
*
* @return void
*/
public function boot()
{
$this->registerPolicies();
Passport::routes();
Passport::tokensCan([
'place-orders' => 'Place orders',
'check-status' => 'Check order status',
]);
}
Default Scope
If a client does not request any specific scopes, you may configure your Passport server to attach default scope(s) to the token using the setDefaultScope
method. Typically, you should call this method from the boot
method of your application's App\Providers\AuthServiceProvider
class:
use Laravel\Passport\Passport;
Passport::tokensCan([
'place-orders' => 'Place orders',
'check-status' => 'Check order status',
]);
Passport::setDefaultScope([
'check-status',
'place-orders',
]);
Assigning Scopes To Tokens
When Requesting Authorization Codes
When requesting an access token using the authorization code grant, consumers should specify their desired scopes as the scope
query string parameter. The scope
parameter should be a space-delimited list of scopes:
Route::get('/redirect', function () {
$query = http_build_query([
'client_id' => 'client-id',
'redirect_uri' => 'http://example.com/callback',
'response_type' => 'code',
'scope' => 'place-orders check-status',
]);
return redirect('http://passport-app.com/oauth/authorize?'.$query);
});
When Issuing Personal Access Tokens
If you are issuing personal access tokens using the App\Models\User
model's createToken
method, you may pass the array of desired scopes as the second argument to the method:
$token = $user->createToken('My Token', ['place-orders'])->accessToken;
Checking Scopes
Passport includes two middleware that may be used to verify that an incoming request is authenticated with a token that has been granted a given scope. To get started, add the following middleware to the $routeMiddleware
property of your app/Http/Kernel.php
file:
'scopes' => \Laravel\Passport\Http\Middleware\CheckScopes::class,
'scope' => \Laravel\Passport\Http\Middleware\CheckForAnyScope::class,
Check For All Scopes
The scopes
middleware may be assigned to a route to verify that the incoming request's access token has all of the listed scopes:
Route::get('/orders', function () {
// Access token has both "check-status" and "place-orders" scopes...
})->middleware(['auth:api', 'scopes:check-status,place-orders']);
Check For Any Scopes
The scope
middleware may be assigned to a route to verify that the incoming request's access token has at least one of the listed scopes:
Route::get('/orders', function () {
// Access token has either "check-status" or "place-orders" scope...
})->middleware(['auth:api', 'scope:check-status,place-orders']);
Checking Scopes On A Token Instance
Once an access token authenticated request has entered your application, you may still check if the token has a given scope using the tokenCan
method on the authenticated App\Models\User
instance:
use Illuminate\Http\Request;
Route::get('/orders', function (Request $request) {
if ($request->user()->tokenCan('place-orders')) {
//
}
});
Additional Scope Methods
The scopeIds
method will return an array of all defined IDs / names:
use Laravel\Passport\Passport;
Passport::scopeIds();
The scopes
method will return an array of all defined scopes as instances of Laravel\Passport\Scope
:
Passport::scopes();
The scopesFor
method will return an array of Laravel\Passport\Scope
instances matching the given IDs / names:
Passport::scopesFor(['place-orders', 'check-status']);
You may determine if a given scope has been defined using the hasScope
method:
Passport::hasScope('place-orders');
Consuming Your API With JavaScript
When building an API, it can be extremely useful to be able to consume your own API from your JavaScript application. This approach to API development allows your own application to consume the same API that you are sharing with the world. The same API may be consumed by your web application, mobile applications, third-party applications, and any SDKs that you may publish on various package managers.
Typically, if you want to consume your API from your JavaScript application, you would need to manually send an access token to the application and pass it with each request to your application. However, Passport includes a middleware that can handle this for you. All you need to do is add the CreateFreshApiToken
middleware to your web
middleware group in your app/Http/Kernel.php
file:
'web' => [
// Other middleware...
\Laravel\Passport\Http\Middleware\CreateFreshApiToken::class,
],
{note} You should ensure that the
CreateFreshApiToken
middleware is the last middleware listed in your middleware stack.
This middleware will attach a laravel_token
cookie to your outgoing responses. This cookie contains an encrypted JWT that Passport will use to authenticate API requests from your JavaScript application. The JWT has a lifetime equal to your session.lifetime
configuration value. Now, since the browser will automatically send the cookie with all subsequent requests, you may make requests to your application's API without explicitly passing an access token:
axios.get('/api/user')
.then(response => {
console.log(response.data);
});
Customizing The Cookie Name
If needed, you can customize the laravel_token
cookie's name using the Passport::cookie
method. Typically, this method should be called from the boot
method of your application's App\Providers\AuthServiceProvider
class:
/**
* Register any authentication / authorization services.
*
* @return void
*/
public function boot()
{
$this->registerPolicies();
Passport::routes();
Passport::cookie('custom_name');
}
CSRF Protection
When using this method of authentication, you will need to ensure a valid CSRF token header is included in your requests. The default Laravel JavaScript scaffolding includes an Axios instance, which will automatically use the encrypted XSRF-TOKEN
cookie value to send a X-XSRF-TOKEN
header on same-origin requests.
{tip} If you choose to send the
X-CSRF-TOKEN
header instead ofX-XSRF-TOKEN
, you will need to use the unencrypted token provided bycsrf_token()
.
Events
Passport raises events when issuing access tokens and refresh tokens. You may use these events to prune or revoke other access tokens in your database. If you would like, you may attach listeners to these events in your application's App\Providers\EventServiceProvider
class:
/**
* The event listener mappings for the application.
*
* @var array
*/
protected $listen = [
'Laravel\Passport\Events\AccessTokenCreated' => [
'App\Listeners\RevokeOldTokens',
],
'Laravel\Passport\Events\RefreshTokenCreated' => [
'App\Listeners\PruneOldTokens',
],
];
Testing
Passport's actingAs
method may be used to specify the currently authenticated user as well as its scopes. The first argument given to the actingAs
method is the user instance and the second is an array of scopes that should be granted to the user's token:
use App\Models\User;
use Laravel\Passport\Passport;
public function test_servers_can_be_created()
{
Passport::actingAs(
User::factory()->create(),
['create-servers']
);
$response = $this->post('/api/create-server');
$response->assertStatus(201);
}
Passport's actingAsClient
method may be used to specify the currently authenticated client as well as its scopes. The first argument given to the actingAsClient
method is the client instance and the second is an array of scopes that should be granted to the client's token:
use Laravel\Passport\Client;
use Laravel\Passport\Passport;
public function test_orders_can_be_retrieved()
{
Passport::actingAsClient(
Client::factory()->create(),
['check-status']
);
$response = $this->get('/api/orders');
$response->assertStatus(200);
}


The best of our fields, transformed into valuable products.
Our agave comes from different and very carefully selected regions, ensuring that the weather, soil and altitude are propitious for their optimal development, all this in order to get the raw materials that would allow us, since the beginning of our process, to ensure the quality of our products.


The Scholar Theme is a Child Theme of the Genesis Framework, by StudioPress. In order for this theme to work, you must own the Genesis Framework.
I highly recommend the framework, as it's impeccable in almost every corner of development. Slim, beautiful code allows for search engines to easily read your site, allowing for better rankings in search engines like Google and Bing.
The Genesis community is also one of the best I've ever had the privelage of being involved in, so any problems that you have in the future are usually easily and quickly answered if the answer isn't already answered somewhere on the web (highly unlikely).
You can see a full list of benefits by checking out the framework:


--- title: home prices in us date: '2011-04-16T16:05:03+05:30' tags: [] tumblr_url: https://sureshshanmugam.com/post/4656220399/home-prices-in-us ---
Home prices in US